Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 9 of 9 total |
Error 11013 in DBISAM Version 3 |
Thu, Jun 28 2007 4:23 PM | Permanent Link |
Gordon Turner | 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 |
Thu, Jun 28 2007 4:58 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.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 |
Thu, Jun 28 2007 6:19 PM | Permanent Link |
"Robert" | "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 |
Fri, Jun 29 2007 8:43 AM | Permanent Link |
Gordon Turner | 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 |
Fri, Jun 29 2007 8:55 AM | Permanent Link |
Gordon Turner | 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 |
Fri, Jun 29 2007 1:53 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.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 |
Fri, Jun 29 2007 1:55 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Fri, Jun 29 2007 3:46 PM | Permanent Link |
Gordon Turner | 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 |
Mon, Jul 2 2007 12:47 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.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 |
This web page was last updated on Sunday, May 19, 2024 at 08:46 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |