"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

<< 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 ?

=================

Tim,

I apologize for my bad writing. We ALL know that this is not a bug in DBISAM.

I am NOT trying to say that this is a bug in DBISAM, or that a little code tweak by
Elevate would magically make this problem go away.

(How else can I say this? My writing is sooo badly the english.)

But this problem IS a weakness in DBISAM (in that we do not have this problem when we use
other database engines or systems).


And allow me to suggest, in the most gentle way, that...

Wait.

Let's all take two deeeeeeeeeeeeeeeeeep breaths.

Inhaaaaaaaaaaaaaaaaaaaaaaaaaaaale

Exhaaaaaaaaaaaaaaaaaaaaaaaaaaaale

Inhaaaaaaaaaaaaaaaaaaaaaaaaaaaale

Exhaaaaaaaaaaaaaaaaaaaaaaaaaaaale


(I feel better already!)

Allow me to suggest that we think about what dbrepair is and does.

DBRepair exists .... why?

No one really needs DBRepair, because:

Computers are perfect
Windows has no weaknesses and no bugs
DBISAM is the best piece of code ever written.


Now that third item is ABSOLUTELY TRUE.

I thank Tim every morning when I get up (if you think that is not true, it is because we
have never met!).

But, unfortunately, the first two items are NOT TRUE.

Damage happens.

And one way damage happens is due to @#$@#$@#@#$ anti spyware programs.

This damage is known, documented, consistent, persistent, and VERY COSTLY to the DBISAM
universe (we are ALL susceptible, but many have been lucky).

This damage is also, from everything I know about it, repairable.


So I ask us to consider: If DBRepair exists;

AND there is a known area of DBISAM data that can be damaged

AND if this damage causes DBISAM to malfunction (in this case, the tables cannot be opened)

AND if this area can be repaired without data loss


Then, in an ideal world, would DBRepair fix this damage?

"Sam Jones" <rafael@zfirmllc.com> wrote in message
news:83AF8A50-0A1A-49AD-9A42-4A02BA729956@news.elevatesoft.com...
>
> Then, in an ideal world, would DBRepair fix this damage?
>

As Tim indicated in another message, there is no way of knowing when the
bolb file is missing if it is due to AV removing it, or somebody going with
explorer and deleting it, or what. That's why I suggested the extension name
change. I think if you have the source code, you can change the extension.

Robert

Sam:

In the previous thread on this subject, it was stated or suggested that
McAfee was one of the biggest AV culprits in causing this to happen.
Yet I run McAfee AV and have for quite a while now and I have never
experienced the deletion of any empty BLB files due to running an AV
event. This is not a DBISAM "is broken" or even a "weakness" in DBISAM.
You mention it not occuring with other databases. Do these databases
use the same extensions for files as does DBISAM? If not you are
comparing apples and oranges.

I agree with Tim that it is an AV issue and not a DBISAM issue but my
point here is that the AV you or your clients are using may not be the
only culprit. Since others running the same AV that I do (albeit
possibly configured differently), running the same DBISAM version I do
(using the default extensions) as well as other similarities (i.e., OS,
etc.) have had this issue occur and I haven't...it leads me to believe
that there might be something else going on behind the scenes. I cannot
begin to tell you what the magic formula is which causes this to occur
but since this isn't a DBISAM issue I personally see no point in Tim
creating a utility to fix something which DBISAM didn't break.

I agree with others who have stated that if this is a show stopper
issue for you, you should recompile with different extensions
configured.

--
Regards,
Jan Ferguson [Team Elevate]


Sam Jones wrote:
<<<< 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.
<<=================
<<
<<Tim,
<<
<<I apologize for my bad writing. We ALL know that this is not a bug in
<<DBISAM.
<<
<<But this problem IS a weakness in DBISAM (in that we do not have this
<<problem when we use other database engines or systems).

Jan,

Thank you for the suggestions!

Some notes:

a) This problem does not affect all users of AV or anti spyware. However it DOES affect
many anti spyware users in particular. There is a 'bad software definition file' for some
anti spyware systems that includes a signature for DBISAM blb files. (Tim knows all the
details on this.)

The bottom line is: It is GREAT that you have never had any issues. My job is to fix this
for my users... and I would love to 'be done and over it!'


b) Using a different extension for the file name: We would LOVE to!!!

Please help us think this through. I have considered this option (from the first moment!),
but just can't think of how to do it.

Here is what we understand:

As we understand it, to change the file extension we need to set a global property in DBISAM.

We have many thousands of existing installations, with the standard DBISAM naming.

Where we need help: How do we change the extension in a way that our code will work
against both new and existing DBISAM databases? (with old and new naming) ?

How does renaming help our existing installations?



Thank you very very much.
And I apologize for all my poor statements. I really did not mean to offend anyone, and
DBISAM is truly the world's best.

"Sam Jones" <rafael@zfirmllc.com> wrote in message
news:A8D16E57-0D00-4DAA-B1C0-EC7A0521CC0F@news.elevatesoft.com...
>
> Where we need help: How do we change the extension in a way that our code
> will work
> against both new and existing DBISAM databases? (with old and new naming)
> ?
>
> How does renaming help our existing installations?
>

Assuming you use file sharing, first thing you do, before you open any table
or execute any query, is to look for all *.BLB and rename them to *.XLB or
whatever your new name is. In C/S you'd do basically the same thing, but in
the server. For multi-user, you need to set up some exclusive ownership of
the database, so that you don't get somebody else trying to do the same
renames at the same time. Basically, the first guy with the new program
renames the BLB fiels for everybody.

This is similar to the way some folks do database reconfigurations. Same
principle.

1. See if there are any BLB files. If not, exit.
2. Lock the database.
3. Get a list of BLB files again (in case someone snuck in and changed the
file names)
4. Rename all the files
5. Unlock the database.

Robert

Sam:

Yes indeed...I am lucky as have been my clients but I know that you and
others have not been so lucky. While I have not had actual experience
in converting thousands of current customers over to a new set of
extensions, my first thought would be to compartmentalize your task.
How do you put out new releases? I would begin thinking of it in that
regard.

First I would be concerned with assisting those who have contacted you
with this issue. Obviously they know about the problem so notify them
that this new minor upgrade/bug fix will take care of the issue. We
know that not all customers upgrade and that would be their choice. But
given the choice of an application failing or installing a minor
upgrade, I think they will perform the upgrade.

From the DBISAM manual/TDBISAMEngine.TableBlobExtension Property
section, "Use the TableBlobExtension to specify the file extension used
by the engine for the physical BLOB file that makes up part of a
logical DBISAM table. The default value is ".blb". Be sure to always
include the filename extension separator (.) when specifying the file
extension. Note: This property cannot be set while the engine is active
and the TDBISAMEngine Active property is True."

Then either programmatically or with instructions to the customer,
change the extensions of all your BLB  files in the data directory, or
if they have been deleted include a new blank copy with the install
which will only be installed if the file does not exist.

Once the initial customers with the AV issues have been taken care of
roll out the new upgrade to those who are not having the AV issue.

Since I don't know what type of application(s) you have that we are
speaking about, this might seem too simplistic and I don't mean to
point out the obvious. You asked me to help you "think this through."
This is how I would handle it with my limited knowledge of your
business and situation.

<<And I apologize for all my poor statements. I really did not mean to
<<offend anyone, and DBISAM is truly the world's best.

I did not take offense. With regard to Tim writing a DBRepair program,
Spock in Star Trek put it best when he said, "...logic clearly dictates
that the needs of the many outweigh the needs of the few."

--
Regards,
Jan Ferguson [Team Elevate]


Sam Jones wrote:

<<Jan,

<<Some notes:
<<
<<a) This problem does not affect all users of AV or anti spyware.
<<However it DOES affect many anti spyware users in particular. There
<<is a 'bad software definition file' for some anti spyware systems
<<that includes a signature for DBISAM blb files. (Tim knows all the
<<details on this.)

I am aware of this. Yet obviously it is still an issue for some.

Sam,

<< But this problem IS a weakness in DBISAM (in that we do not have this
problem when we use other database engines or systems). >>

It's only a weakness in the same sense that having your ID stolen, and
having that ID subsequently used to rip off other people with bad checks, is
a personal weakness for you.  You haven't done anything to cause any of the
damage, nor can you fix the damage that has been done to others.  You've
been used to cause damage to others, and you can't do a thing about it.
That's the position that we're in.

<< Then, in an ideal world, would DBRepair fix this damage? >>

As Robert indicated, and as I did prior to him, the repair functionality
can't possibly know what state the .BLB file was in prior to it going
missing, so recreating an empty .BLB is not an option.

The only other option is for you to change your file extensions so that the
anti-spyware stops deleting the .BLB files.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thank you!

We have carefully walked the path of renaming the blb files, and we just can't. It is
simply too late for us. (If building a new application, FOR SURE do this!!!) I know it
looks easy, and the path seems clear, but when we walk the path, with a large stack of
sites, and all the different configs and network permissions, etc etc out there, it spells
a disaster.

(Renaming data files on an already distributed app, that uses both direct client, and
client/server, and network and local and shared access, from multiple desktops.... )


The next option we see is to instrument dbrepair itself to do this. For us, this is a
proper solution. Database damaged? Do a repair.

That works in concept, and in practice. (Doesn't matter what caused the damage, could be
anything.)

We are hesitant to package up blb files and redistribute them, and we are hesitant, in
general, about trying to 'fool' dbisam. DBISAM knows how to create a blb file. Our code
does not.

That is why it seems to us that DBISAM itself could have some smarts (or a special func,
or ?) to recreate the blb file. We just want DBISAM to create a 'known good and valid,
true DBISAM' blb for a given table.


Is it possible to open a paid or hourly support incident to facilitate such a feature in
DBISAM ?

You may not be able to do it safely today, but how about implementing
the ability to lock your database exclusively through either semaphores
(note that I have never used them), a non-DBISAM control file using
ordinary shared and exclusive file locks, or some other method. Once you
can ensure exclusive access to the database in the subsequent version of
your application, rename the .BLB files before opening any tables with
the new engine extensions. Doesn't help you today, but at least gives
you a near-term solution.

Sean






Sam Jones wrote:
> Thank you!
>
> We have carefully walked the path of renaming the blb files, and we just can't. It is
> simply too late for us. (If building a new application, FOR SURE do this!!!) I know it
> looks easy, and the path seems clear, but when we walk the path, with a large stack of
> sites, and all the different configs and network permissions, etc etc out there, it spells
> a disaster.
>
> (Renaming data files on an already distributed app, that uses both direct client, and
> client/server, and network and local and shared access, from multiple desktops.... )
>
>
> The next option we see is to instrument dbrepair itself to do this. For us, this is a
> proper solution. Database damaged? Do a repair.
>
> That works in concept, and in practice. (Doesn't matter what caused the damage, could be
> anything.)
>
> We are hesitant to package up blb files and redistribute them, and we are hesitant, in
> general, about trying to 'fool' dbisam. DBISAM knows how to create a blb file. Our code
> does not.
>
> That is why it seems to us that DBISAM itself could have some smarts (or a special func,
> or ?) to recreate the blb file. We just want DBISAM to create a 'known good and valid,
> true DBISAM' blb for a given table.
>
>
> Is it possible to open a paid or hourly support incident to facilitate such a feature in
> DBISAM ?
>

Sam


From what I seem to recall of this issue its only empty .blbs that get zapped so you have an easy option.

1. back at base create a table with a .blb file, rename it to something like justincaseitszapped.xxx
2. ship this file out to every site
3. when a repair is needed check through the files making up the tables and if there should be a .blb file but isn't simply copy the justincaseitszapped.xxx and rename it to table.blb
4. run the normal repair

That's it, no magic or anything else. Simple to do, doesn't need a change in DBISAM and should cure the problem

OTOH if the .blbs have data in them you need to find some way to alter the extensions.

Roy Lambert [Team Elevate]