I'm using D7 and (for this product at this time) version 3.24 of DBISam.
 I have a customer running McAfee Enterprise version 8 who is getting
11010 messages when the program starts.  (I open several queries right
after opening all of my database tables.)

I've seen previous posts about the .DAT file being deleted by anti-virus
programs.  The curious thing is that I set the PrivateDir value of the
session to the same folder as the data files.  When the program starts,
it creates the data files, but then fails with the 11010 message right
after that because the temp .DAT file created in the data folder gets
deleted.

So what's different about the temp .DAT files than the table .DAT files
that an anti-virus program would ignore one and delete the other?  Are
there any other solutions short of upgrading the product to use version
4 of DBISAM?

(Please don't suggest changing AV programs.  I'm not in a position to
tell my customers what AV they should be using.  My product needs to run
in spite of the AV programs.)

Gordon,

<< So what's different about the temp .DAT files than the table .DAT files
that an anti-virus program would ignore one and delete the other? >>

You'll have to ask the AV vendor what their logic is regarding this.  It
varies from product to product.

<< Are there any other solutions short of upgrading the product to use
version 4 of DBISAM? >>

If you have the source code to DBISAM, I can send you the changes necessary
to make the extensions .TMP for temporary query result tables.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

When you create the temp table files are you using the Windows API to set the
property "delete on close"?

If so, maybe the antivirus is opening and closing the file before your code
does, and on closing, Windows does what it has been told to do.

--Bill Sparrow--

Bill,

<< When you create the temp table files are you using the Windows API to set
the property "delete on close"? >>

Yes, but only during the Open for the temporary table, not for the creation.
The temporary table is created, closed, and then opened.

<< If so, maybe the antivirus is opening and closing the file before your
code does, and on closing, Windows does what it has been told to do. >>

There should be no way for the AV software to interject API calls into the
application.  It can hook the low-level file system as a driver, of course,
but I don't think it can (or at least should) modify what the application is
requesting in terms of the Win32 API parameters, etc.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

> If you have the source code to DBISAM, I can send you the changes necessary
> to make the extensions .TMP for temporary query result tables.

Thanks for the offer, but I bit the bullet and upgraded the app to
version 4, just for this one customer.  I had planned to do this in the
long run anyway, but hadn't had time to deal with automatic conversion
of the existing data file.

Gordon,

<< Thanks for the offer, but I bit the bullet and upgraded the app to
version 4, just for this one customer.  I had planned to do this in the
long run anyway, but hadn't had time to deal with automatic conversion of
the existing data file. >>

That's good to hear.  I'm sure that you won't be sorry that you made that
decision.

--
Tim Young
Elevate Software
www.elevatesoft.com

To return to this issue, I was not implying that the AV software could
interject API calls into the application, merely that in the multitasking
environment, it can do things to the file in between your various API calls.

I think it is safe to assume that the AV software is "watching" for files
being created and is receiving notifications.  So, if it gets a notification
immediately after you create the file, or after you close it, then it might
open the file before you get a chance to open it yourself.  Since you are
using special attributes to open the temporary table's file that you don't
use to open a normal table's file, the open could fail due to those options
being incompatible where the file is already open.

So, where people are asking the question "why should the AV software behave
differently for a temporary table versus a normal table", maybe the question
should be rephrased as "why is DBISAM's reaction to the AV software different
for temporary tables compared to normal tables"?  And the answer could be the
attributes or mode used to open the file.

--Bill Sparrow--


In article <BF0BBE9D-32DD-4EC1-AB94-05FF0D484EAF@news.elevatesoft.com>,
timyoung@elevatesoft.com (Tim Young [Elevate Software]) wrote:

> *Subject:* Re: Error 11010
> *From:* "Tim Young [Elevate Software]" <timyoung@elevatesoft.com>
> *Date:* Thu, 12 Jan 2006 11:26:40 -0500
>
> Bill,
>
> << When you create the temp table files are you using the Windows API to
set
> the property "delete on close"? >>
>
> Yes, but only during the Open for the temporary table, not for the
creation.
> The temporary table is created, closed, and then opened.
>
> << If so, maybe the antivirus is opening and closing the file before your
> code does, and on closing, Windows does what it has been told to do. >>
>
> There should be no way for the AV software to interject API calls into the
> application.  It can hook the low-level file system as a driver, of course,
> but I don't think it can (or at least should) modify what the application
is
> requesting in terms of the Win32 API parameters, etc.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>
>

Bill,

<< To return to this issue, I was not implying that the AV software could
interject API calls into the application, merely that in the multitasking
environment, it can do things to the file in between your various API calls.
>>

Temporary tables are opened exclusively.  There should be no way that an
external process could interfere with the files once they are open.  What is
happening in this case, however, is that DBISAM is creating the temporary
table, closing it, and then re-opening it exclusively.  That is what allows
the AV software to delete or move the file and causes an error in DBISAM.

<< I think it is safe to assume that the AV software is "watching" for files
being created and is receiving notifications.  So, if it gets a notification
immediately after you create the file, or after you close it, then it might
open the file before you get a chance to open it yourself.  >>

100% correct.

--
Tim Young
Elevate Software
www.elevatesoft.com

So the only solution you can provide is a change to version 4?

Is that correct? no work-around no other possibility than telling our customter to choose another AV-guard.

sorry but this sounds like marketing strategy, .. we don't fix this problem in your bought version, buy ne next higher one ^_^

I think we maybe should change our db-engine if this really is your only way of providing solutions.

> sorry but this sounds like marketing strategy, .. we don't fix this
problem in your bought version, buy ne next higher one ^_^

You've never purchased any software that had new features in a newer
version? Microsoft changes SQL Server nearly every year by adding new
features. If software developers, you included, never updated their
products and continually added new features to current products, we'd
still be at "ProductName 1.0.0"

> I think we maybe should change our db-engine if this really is your
only way of providing solutions.

Both of these statements by you are really unfair. Tim does a great job
in fixing bugs and other discrepancies in DBIsam and is very attentive
to requests from developers. Check these newsgroups for the many
discussions on AV product reactions to data files. This itself was a
requested feature he added into v4.xx. The discussions and requests
came during the version 4.xx lifecycle, not the 3.xx lifecycle. He is
now working on v5.0 and probably has a strange aversion to not feeding
his family, buying clothes, paying the mortgage, etc.

Call it marketing to upgrade features in newer versions...Yes; but
please DO NOT infer that Tim is doing this as a ploy to get you to buy
an upgrade because he doesn't care about helping you fix your problem!
That's just wrong!

As a consultant/programmer you should tell your customer all the good
news and bad news and the reasons for them. Then let THEM make up THEIR
minds as to how they can assist you in resolving the problem.

My two cents worth...

--
Regards,
Jan Ferguson


Andri Kleinschmidt wrote:

> So the only solution you can provide is a change to version 4?
>
> Is that correct? no work-around no other possibility than telling our
> customter to choose another AV-guard.
>
> sorry but this sounds like marketing strategy, .. we don't fix this
> problem in your bought version, buy ne next higher one ^_^
>
> I think we maybe should change our db-engine if this really is your
> only way of providing solutions.

Andri