I have been unable to solve the problem causing the 11013 access denied errors on my temp tables.  (v4.24 build 1)

I've read the posts regarding anti-virus interfering with DBISAM's temp files so I tried renaming them to .tmpblb, .tmpdat, .tmpidx  but
that didn't work.  I then tried using .tmpb, .tmpd, .tmpi   but that did not work either.   I've confirmed that the temp files are being
created in a local path under C:\Documents and Settings\{user-name}\Local Settings\Temp.  I also changed the
DBISAMEngine.CreateTempTablesInDatabase := True  (but I realize that is relevant to a different issue I think).

I am running McAfee and have noticed if I change my AV option settings to scan "Program Files and Documents only" the 11013
problem goes away. But I can't insist that all my customers do this.  

What am I missing here?  How may I solve this problem?  Thank you!

Rick Leffler
Leffler Systems

Rick,

<< I am running McAfee and have noticed if I change my AV option settings to
scan "Program Files and Documents only" the 11013
problem goes away. But I can't insist that all my customers do this.

What am I missing here?  How may I solve this problem?  Thank you! >>

You're not missing anything - the problem is McAfee, pure and simple.  If
they don't provide an option to not scan everything, then you have to use
the restricted scanning option if you want the problem to go away.

--
Tim Young
Elevate Software
www.elevatesoft.com

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

You're not missing anything - the problem is McAfee, pure and simple.  If
they don't provide an option to not scan everything, then you have to use
the restricted scanning option if you want the problem to go away.

---------------------

Tim,
Sorry to be a pest but I am getting more and more users complaining about DBISAM Engine Error #11013 Access denied to table or backup file
####.  They're not happy with me telling them to alter their AV settings.  It's not just McAfee either, I've seen this with Norton and at least one
other brand of AV.

Is there a time-out setting I can adjust on the engine or is there anything else I can do?  Surely I'm not the only one experiencing this problem, am
I?  Thanks.

Rick Leffler

Rick
> Tim,
> Sorry to be a pest but I am getting more and more users complaining about
> DBISAM Engine Error #11013 Access denied to table or backup file
> ####.  They're not happy with me telling them to alter their AV settings.
> ####It's not just McAfee either, I've seen this with Norton and at least
> ####one
> other brand of AV.
>
> Is there a time-out setting I can adjust on the engine or is there
> anything else I can do?  Surely I'm not the only one experiencing this
> problem, am
> I?  Thanks.
You are certainly not the only one having problems with AV software:

http://support.microsoft.com/kb/823166/en-us

This isn't really a solution but it might help you to convince your
customers to change their AV settings.

Bernd Kuhlmann

Could the database engine's temp files be created in MEMORY instead of on disk? Would that eliminate the 11013 errors?
If so, could I get a code sample of how to redirect them to memory?  Thanks.

Rick,

have you tried to assign specific directory with all possible rights as
Session.PrivateDir where all temporary files will reside? In some cases this
is solution for problems you have.

Iztok Lajovic


"Rick Leffler" <rleffler@mailbag.com> je napisal v sporoèilo
news:B0D6D86B-38F8-4426-860D-3161A616F429@news.elevatesoft.com ...
>I have been unable to solve the problem causing the 11013 access denied
>errors on my temp tables.  (v4.24 build 1)
>
> I've read the posts regarding anti-virus interfering with DBISAM's temp
> files so I tried renaming them to .tmpblb, .tmpdat, .tmpidx  but
> that didn't work.  I then tried using .tmpb, .tmpd, .tmpi   but that did
> not work either.   I've confirmed that the temp files are being
> created in a local path under C:\Documents and Settings\{user-name}\Local
> Settings\Temp.  I also changed the
> DBISAMEngine.CreateTempTablesInDatabase := True  (but I realize that is
> relevant to a different issue I think).
>
> I am running McAfee and have noticed if I change my AV option settings to
> scan "Program Files and Documents only" the 11013
> problem goes away. But I can't insist that all my customers do this.
>
> What am I missing here?  How may I solve this problem?  Thank you!
>
> Rick Leffler
> Leffler Systems
>

Rick,

<< Could the database engine's temp files be created in MEMORY instead of on
disk? Would that eliminate the 11013 errors? If so, could I get a code
sample of how to redirect them to memory?  Thanks. >>

Unfortunately, DBISAM can only direct temporary tables to disk.  Frankly, I
would find a way at the very least to use CreateTempTablesInDatabase=True
and prevent the AV software from scanning your database directories.  Having
them scan the database tables is probably causing your app's performance to
really take a hit anyways.

--
Tim Young
Elevate Software
www.elevatesoft.com

but doesn't

 "select ..... into memory\tmp... "

get around the problem?  You have to remember that you created an in
memory table of course.

Jon


Tim Young [Elevate Software] wrote:
> Rick,
>
> << Could the database engine's temp files be created in MEMORY instead of on
> disk? Would that eliminate the 11013 errors? If so, could I get a code
> sample of how to redirect them to memory?  Thanks. >>
>
> Unfortunately, DBISAM can only direct temporary tables to disk.  Frankly, I
> would find a way at the very least to use CreateTempTablesInDatabase=True
> and prevent the AV software from scanning your database directories.  Having
> them scan the database tables is probably causing your app's performance to
> really take a hit anyways.
>

Jon,

<< but doesn't

 "select ..... into memory\tmp... "

get around the problem?  You have to remember that you created an in memory
table of course. >>

For queries, yes, you are correct.  I was under the impression that his
issue was *all* temporary tables, but that may just be down to my shoddy
reading comprehension since I'm speed reading these messages every day.

--
Tim Young
Elevate Software
www.elevatesoft.com

or my skimming of the messages in the first place

Jon

Tim Young [Elevate Software] wrote:
> Jon,
>
> << but doesn't
>
>   "select ..... into memory\tmp... "
>
>  get around the problem?  You have to remember that you created an in memory
> table of course. >>
>
> For queries, yes, you are correct.  I was under the impression that his
> issue was *all* temporary tables, but that may just be down to my shoddy
> reading comprehension since I'm speed reading these messages every day.
>