Chris,

<< Does anyone know if AOL/CA are doing anything to address this? >>

I'll see if I can get in touch with the lawyer this week and see if they
have responded at all.  I've been very busy, so I haven't been able to
follow-up on this issue.

--
Tim Young
Elevate Software
www.elevatesoft.com

How about extending the dbrepair functionality to address cases of missing .blb
files?

Sam,

<< How about extending the dbrepair functionality to address cases of
missing .blb files? >>

How, exactly ?  As soon as it recreates the .BLB file, the anti-spyware will
simply remove it again.

--
Tim Young
Elevate Software
www.elevatesoft.com

This issue continues to be a large, burning issue for us.

We really need help from the DBISAM team on this.


In one post, there was this Q&A:

>>>>>>>>>>>>>>>
<< How about extending the dbrepair functionality to address cases of
missing .blb files? >>

How, exactly ?  As soon as it recreates the .BLB file, the anti-spyware will
simply remove it again.
<<<<<<<<<<<<<<<

No, you misunderstand the story.

First: The anti spyware apps do not immediately delete the blb files. When we put them
back, it takes 3-7 days for them to get removed again (part of a weekly sweep or something).

Second: Only empty blb files are deleted (as someone here noted awhile ago). This is not a
data loss issue, it is a "DBISAM is broken" issue.

Third: What we need is that after a DBRepair has been done, that the database can be
opened. The problem we have is that there is no way for us to fix the database, short of
manually copying in these files from another system.


This issue is costing us many hours in support each week.

Please please help us out here.

Thank you!

Sam,

> No, you misunderstand the story.
>
> First: The anti spyware apps do not immediately delete the blb files. When
> we put them
> back, it takes 3-7 days for them to get removed again (part of a weekly
> sweep or something).
>
> Second: Only empty blb files are deleted (as someone here noted awhile
> ago). This is not a
> data loss issue, it is a "DBISAM is broken" issue.
>
> Third: What we need is that after a DBRepair has been done, that the
> database can be
> opened. The problem we have is that there is no way for us to fix the
> database, short of
> manually copying in these files from another system.
>
> This issue is costing us many hours in support each week.
>
> Please please help us out here.

Technically this isn't a DBISAM issue, since it's pretty much the same thing
as someone manually deleting files using Windows explorer.  While it would
be nice to have DBISAM be able to repair this situation automatically, this
really is something that you will need to implement yourself.

What we do in the latest release of our application is to embed an empty blb
file within the application that we can push out to the database folder if
it's determined that the cause of the error is a missing blob.  It's not
easy and requires a bit of work, especially if you are running a
client/server configuration.

Here are the steps that we take during our repair function process:

1. Trap the open table error with regards to a missing file.

2. Check our table definitions (we store these within the application
itself) to determine if a blob file should exist on the table throwing the
error.

3. If it does not have a blob file defined, we simply re-raise the exception
and let the standard error handling process the error.

4. If the table should have a blob file, we do a physical FileExists check
against a local database or call a custom server function to do the blb file
check on the server side.

5. If the blb file is missing but the other dat and idx files are present,
we push the embedded empty blb file out to the database directory.  Again,
we call a custom server function to do this if it's a client/server
configuration.

6. After pushing out the missing blb file, we run a table repair against the
table.

Hope this helps.

--

---------------------------------------
 Terry Swiers
 Millennium Software, LLC
 http://www.1000years.com
 http://www.atrex.com

 Atrex Inventory Control/POS -
    Big business features without spending big business bucks!

Atrex Electronic Support Options:
 Atrex Knowledgebase: http://www.atrex.com/atrexkb.asp
 Email: mailto:support@atrex.com
 Newsgroup: news://news.1000years.com/millennium.atrex
 Fax: 1-925-829-1851
 Phone: 1-925-828-5892 (M-F, 9a-5p Pacific)
 ---------------------------------------

<< First: The anti spyware apps do not immediately delete the blb files.
When we put them back, it takes 3-7 days for them to get removed again (part
of a weekly sweep or something). >>

It doesn't matter when the anti-spyware apps delete them.  The bottom line
is that they'll get deleted again.

<< Second: Only empty blb files are deleted (as someone here noted awhile
ago). This is not a data loss issue, it is a "DBISAM is broken" issue. >>

This is the second time that you've proceeded to post messages on here
accusing DBISAM of problems that have nothing to do with DBISAM.  This is
*not* a DBISAM issue.  DBISAM isn't doing anything at all here - the
anti-spyware applications are doing it.  What is so hard to understand about
this ?

<< Third: What we need is that after a DBRepair has been done, that the
database can be opened. The problem we have is that there is no way for us
to fix the database, short of manually copying in these files from another
system. >>

I'm sorry, but we couldn't possibly just replace the missing .BLB file with
a new one without any error, etc.  How would DBISAM know that the previous
..BLB file was empty ?  It's gone.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:A4D1386C-0080-45BE-8189-65F9CDDA8556@news.elevatesoft.com...
>
> << First: The anti spyware apps do not immediately delete the blb files.
> When we put them back, it takes 3-7 days for them to get removed again
> (part of a weekly sweep or something). >>
>
> It doesn't matter when the anti-spyware apps delete them.  The bottom line
> is that they'll get deleted again.
>
> << Second: Only empty blb files are deleted (as someone here noted awhile
> ago). This is not a data loss issue, it is a "DBISAM is broken" issue. >>
>
> This is the second time that you've proceeded to post messages on here
> accusing DBISAM of problems that have nothing to do with DBISAM.  This is
> *not* a DBISAM issue.  DBISAM isn't doing anything at all here - the
> anti-spyware applications are doing it.  What is so hard to understand
> about this ?
>
> << Third: What we need is that after a DBRepair has been done, that the
> database can be opened. The problem we have is that there is no way for us
> to fix the database, short of manually copying in these files from another
> system. >>
>
> I'm sorry, but we couldn't possibly just replace the missing .BLB file
> with a new one without any error, etc.  How would DBISAM know that the
> previous .BLB file was empty ?  It's gone.
>


Are the files deleted because they are BOTH 1) *.BLB and 2) empty?

Robert

Robert,

<< Are the files deleted because they are BOTH 1) *.BLB and 2) empty? >>

As far as I know they are deleted because they match some "signature" that
the anti-spyware software uses to determine the match.   I believe that this
"signature" is the file extension and the file contents, so yes, effectively
that is the case.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:74F35D4D-E85D-4FE7-8027-0112626B0045@news.elevatesoft.com...
> Robert,
>
> << Are the files deleted because they are BOTH 1) *.BLB and 2) empty? >>
>
> As far as I know they are deleted because they match some "signature" that
> the anti-spyware software uses to determine the match.   I believe that
> this "signature" is the file extension and the file contents, so yes,
> effectively that is the case.
>
> --

You think you could provide a simple way to change the extensions without
having to recompile all the database programs? Some type of configuration
file that if present would be opened and processed before any database
access is attempted, and would tell the engine what extensions to use? Seems
that would solve the problem. I have not run into this problem, but I can
certainly sympathize with the nightmare it must be. And one is reluctant to
invest a lot in custom changes to applications plus as you say the msissing
blb file is no 100% evidence that it was empty when it was deleted, but
maybe you can do a simple extension name change at a very basic level with
not much effort, since you already provide for extension customizing anyway.

Robert

Robert,

<< You think you could provide a simple way to change the extensions without
having to recompile all the database programs? Some type of configuration
file that if present would be opened and processed before any database
access is attempted, and would tell the engine what extensions to use? >>

I would be reluctant at this point to introduce an external configuration
file for such a thing, especially when the application vendor can do so
themselves in a manner that is more fitting to their situation.

--
Tim Young
Elevate Software
www.elevatesoft.com