I have a customer who is getting the 11013 error on a temporary table
created by my app (Delphi 7 and DBISAM 3.24, shared file database).
I've encountered this problem before and it is usually caused by an AV
program automatically deleting any .DAT files in the users Temp folder.
 The solution up to this point has been to set the PrivateDir property
of the Session component to the same folder that the data files are
stored in, the assumption being that if the data files can be created
and updated, the same would be true of the temp files.

Unfortunately, in this case, that change did not resolve the problem.
(The data files are stored in C:\Documents and Settings\All
Users\Application Data\TimeOff\Data.)  I even had the user create a
brand new folder just for the temp files and she still got a 11013
error.  I know that she is the only user of the program, but since the
temp files are created by queries executed within the program, and not
by my code, I would expect that they would be created and opened in
whatever mode is necessary to the DBISAM engine.

The query in question is failing on the Prepare statement...

  NewQuery := TDBISAMQuery.Create(nil);
  NewQuery.SessionName := TimeOffDataMod.TimeOffSession.SessionName;
  NewQuery.DatabaseName := TimeOffDataMod.TimeOffDB.DatabaseName;
  with NewQuery do begin
    SQL.Add('select * from TimeOff');
    if EmpID = 0 then
      SQL.Add(' where EmpID < 0')
    else
      SQL.Add(' where EmpID = ' + IntToStr(-EmpID));
    SQL.Add(' and WeekDate between '
        + QuotedStr(FormatDateTime('yyyy-mm-dd', StartDate)) + ' and '
        + QuotedStr(FormatDateTime('yyyy-mm-dd', EndDate)));
    Prepare;
    Open;
    while not EOF do begin
      TimeOffRec := TTimeOffRecClass.Create;
      TimeOffRec.EmpID := -1 * FieldByName('EmpID').AsInteger;
      TimeOffRec.ReasonID := FieldByName('ReasonID').AsInteger;
      TimeOffRec.WeekDate := FieldByName('WeekDate').AsDateTime;
      GlobalDeleteList.AddObject(FieldByName('WeekDate').AsString,
            TimeOffRec);
      Next;
    end;
    Close;
    UnPrepare;
    Free;
  end;

It gets fired from a routine executed from within a timer set to 300
milliseconds (refreshing a scrolling screen).  This routine works on
hundreds of other workstations, so I'm not sure why it is failing here.
 Since the routine creates a new TDBISAMQuery component each time, I
would assume the temp file behind the scenes would be a new file each
time as well.

Any suggestions on where to look or what to look at?

--
Gordon Turner
Mycroft Computing
http://www.mycroftcomputing.com

Gordon,

<< I have a customer who is getting the 11013 error on a temporary table
created by my app (Delphi 7 and DBISAM 3.24, shared file database).  I've
encountered this problem before and it is usually caused by an AV program
automatically deleting any .DAT files in the users Temp folder.  The
solution up to this point has been to set the PrivateDir property of the
Session component to the same folder that the data files are stored in, the
assumption being that if the data files can be created and updated, the same
would be true of the temp files. >>

There's really nothing that can be done with this issue with respect to 3.x
except:

1) Turn off the AV scanning or remove it completely (some AV scanners seem
to not respect the "don't scan this directory" setting).

2) Modify the source code to 3.x in order to use a different table extension
for temporary tables.  This may or may not work with later versions of AV
software, which seem to want to quarantine everything that is created in a
directory that it is scanning.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Gordon Turner" <gordon@mycroftcomputing.com> wrote in message
news:7832E9F6-8DD0-4B73-91DD-DC58EB161AA3@news.elevatesoft.com...
>
> It gets fired from a routine executed from within a timer set to 300
> milliseconds (refreshing a scrolling screen).  This routine works on
> hundreds of other workstations, so I'm not sure why it is failing here.

Probably because this computer is faster or slower than the others. Calling
a database routine on a timer? Seems like a recipe for disaster to me. Plus,
if the query gets called that often, why is it not prepared just once?

Procedure TimerFires
// query got prepared somewhere else
if query.active then exit;
set parameters
query.open;
process
query.close;

Robert

Tim Young [Elevate Software] wrote:
>
> There's really nothing that can be done with this issue with respect to 3.x
> except:
>
> 1) Turn off the AV scanning or remove it completely (some AV scanners seem
> to not respect the "don't scan this directory" setting).
>
> 2) Modify the source code to 3.x in order to use a different table extension
> for temporary tables.  This may or may not work with later versions of AV
> software, which seem to want to quarantine everything that is created in a
> directory that it is scanning.

I'm not convinced it is an AV problem.  Otherwise, I would expect
problems with the data files as well as the temp files when the temp
files are created in the same folder as the data files.  The app creates
the data files on it's first startup so they are not already created and
then installed in the folder.

Is there any other reason why a newly created query component would not
be able to access the temp files it creates when preparing a query?

--
Gordon Turner
Mycroft Computing
http://www.mycroftcomputing.com

Robert wrote:
>
> Probably because this computer is faster or slower than the others. Calling
> a database routine on a timer? Seems like a recipe for disaster to me. Plus,
> if the query gets called that often, why is it not prepared just once?
>
> Procedure TimerFires
> // query got prepared somewhere else
> if query.active then exit;
> set parameters
> query.open;
> process
> query.close;

The app displays a 4 week calendar with dated records on a 4 row grid.
On the MouseDown event of a button the 4 week range either scrolls
forward or backwards by starting the timer (to keep the user from having
to continuously click the button to get the view to change).  So the
routine is really...

Procedure TimerFires
set parameters (date ranges)
query.open
process
query.close

Handling the buffering for an expanded date range would be really
complicated for something that works on thousands of machines currently.
 Also, keep in mind that this is a multi-user app, so I'd like to use
the latest data for every query.

I've tested the routine on an old 150Mz machine, so I know it's not
because the computer's too slow and my development machine is a 3Ghz
dual processor and also has no problem.  But, I'm not sure why the speed
of the machine would affect the query component's access to it's own
temp files?
--
Gordon Turner
Mycroft Computing
http://www.mycroftcomputing.com

Gordon,

<< I'm not convinced it is an AV problem. >>

Is there an AV product on the machine ?  If so, then it's most likely an AV
problem.

<< Otherwise, I would expect problems with the data files as well as the
temp files when the temp files are created in the same folder as the data
files.  The app creates the data files on it's first startup so they are not
already created and then installed in the folder. >>

Yes, you would expect this behavior if you were dealing with normal
software.  However, the AV software out there has a lot of ???? type of
behavior when it comes to when and how it determines that it needs to
scan/quarantine files.

<< Is there any other reason why a newly created query component would not
be able to access the temp files it creates when preparing a query? >>

No, other than user rights where someone had create rights but not read
rights.  However, I'm not even sure if that's possible, and it's very
unlikely.

--
Tim Young
Elevate Software
www.elevatesoft.com

Gordon,

Robert may be on to something here, but it all depends upon whether you're
using an OnQueryProgress event handler ?  Is that the case with the query
that you're executing in the timer ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:
> Gordon,
>
> Robert may be on to something here, but it all depends upon whether you're
> using an OnQueryProgress event handler ?  Is that the case with the query
> that you're executing in the timer ?
>

No coded event handlers at all.  Actually, the query procedure that is
failing is called by a different procedure that prepares the data.  The
whole program tracks time not at work.  You can create entries that
apply to individual employees or to all employees. And then you can
create a negation of the all employees entry for individual employees.
(Think company holiday but certain employees still have to work on that
date.)

The larger procedure prepares all of the entries, but the problem
routine prepares the negation entries for the larger procedure to use in
preparing the final data set to be displayed.

--
Gordon Turner
Mycroft Computing
http://www.mycroftcomputing.com

Gordon,

<< No coded event handlers at all. >>

In that case it is very unlikely that the timer by itself is causing
re-entrancy or any other type of issue that would result in DBISAM tripping
over itself in terms of exclusive/non-exclusive access.  My original
suggestion still stands at this point.

--
Tim Young
Elevate Software
www.elevatesoft.com