We have customers who occassionally use anti-virus programs and some of them cause the error ElevateDB Error #600 File manager when EDB tries to clean up temporary files it has created.  The obvious solution on our end is to add an exception to the AV for the temporary directory, but some of our customers are not very tech savvy and we are concerned other users may install our trial program, run into this issue and then just give up on us.

Is there any other solution to keep these files from being checked, or any way to clean these files up manually so this issue does not occur?  Any help or guidance is appreciated.

A little more background...

For us, this conflict occurs mostly at program startup.  AV software is scanning the temporary database files created by EDB (and locking them).  ElevateDB is trying to remove them, but AV has them locked resulting in the error.  Again, is there any good way to handle this to avoid the conflict?

Brian


I think you're going to be out of luck. This has been discussed several times and, unless my memory is failing, the answer is always to exclude the directory.

Depending on just what's happening it may be possible to modify your system. I'm guessing its caused by sql and when queries are closed. If its mainly at start up is it because a lot of people are all logging on at the same time?


Roy Lambert

Yes it is caused by closing a query.  We run a test query at the start of our program just to make sure all the connection settings are correct so we can trap any issues.  The amount of people using our program doesn't matter though.  We had this happen on a single user install of our program without any other registered issues.

We suspected there might not be much we can do other than make an exception in the AV, but figured we could ask in case anyone had a creative work around.

Thanks for the reply.

Brian


If its only one query to check the connection  a couple if ideas have occurred to me:

1. if its an insensitive query change it to sensitive - sensitive queries are essentially filters on the table and as such don't produce a disk file - no file = nothing to be scanned = no problem (I hope)

2. if that's not possible write it in such a way as to produce a small result set - smaller result set means smaller file on disk should mean its scanned faster

3. build in a small delay (sppel should do) to give the AV scan a chance to finish

If anything else crosses my mind I'll let you know

Roy Lambert

Brian


for sppel read sleep

Roy Lambert

Brian,

<< Is there any other solution to keep these files from being checked, or any way to clean these files up manually so this issue does not occur? >>

Have you tried to change your temporary tables path in EDB to something that is *underneath* your database directory ?

For example, have your application directories look like this:

\MyApp -> Configuration File
MyApp\Database1 -> Database 1
MyApp\Temp -> Temporary Tables Path

That may make the AV software more wary of touching anything in the Temp directory, although there is a lot of really dumb AV software out there, so your mileage may vary.

Tim Young
Elevate Software
www.elevatesoft.com

Thank you Tim.  

We tried the sensitive query route that Roy suggested and that worked partially, but there were some queries it would not work for.  Changing the temp directory to one we create in our installer did work for all cases, so the AV ignored directories created on initial install.  

Thanks for the tips everyone they really helped.

Brian,

<< We tried the sensitive query route that Roy suggested and that worked partially, but there were some queries it would not work for.  Changing the temp directory to one we create in our installer did work for all cases, so the AV ignored directories created on initial install. >>

Good, I'm glad that the separate temp directory did the trick.

Tim Young
Elevate Software
www.elevatesoft.com