Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 8 of 8 total |
11013 Access denied |
Wed, May 30 2012 12:06 PM | Permanent Link |
David Darlison | I have an application that collects a file from a printer it converts the file empties the target table using EmptyTable, then runs a query to insert the file into the table. This works fine if I only run it once but as soon as I run it a second time I get a 11013 access error to the table when it comes to emptying the table again.
I have tried everything, preparing & unpreparing the query, changing the PrivateDir of the session. Using the CreateTempTablesToDatabase on an engine but always it is the same. The application is running on a local machine, I have turned off the AV and the OS is XP with full Admin rights. |
Wed, May 30 2012 12:54 PM | Permanent Link |
Raul Team Elevate | This is usually due to another session still having the table open - the empty table command requires exclusive access basically so check if you have any other sessions that are present and have the table open first.
if you use a dedicated session for emptying then either open table exclusively or check for datasets/queries that might use default session (thus the 2nd session). Raul David Darlison wrote: I have an application that collects a file from a printer it converts the file empties the target table using EmptyTable, then runs a query to insert the file into the table. This works fine if I only run it once but as soon as I run it a second time I get a 11013 access error to the table when it comes to emptying the table again. I have tried everything, preparing & unpreparing the query, changing the PrivateDir of the session. Using the CreateTempTablesToDatabase on an engine but always it is the same. The application is running on a local machine, I have turned off the AV and the OS is XP with full Admin rights. |
Wed, Feb 20 2013 5:07 PM | Permanent Link |
John Comloquoy | I am having exactly the same problem as David below. I'm using the "default" session and the first time round the table is emptied but flags Error #11013 on the second call after running a query on it. Setting the Exclusive property makes no difference. Is there a way if finding out what is holding the table? I can write a work-around but prefer to get a better understanding of what's happening! (Win7//Delphi XE3//DBISAM v 4.34 Build 6).
John - - - - - - - - Raul wrote: This is usually due to another session still having the table open - the empty table command requires exclusive access basically so check if you have any other sessions that are present and have the table open first. if you use a dedicated session for emptying then either open table exclusively or check for datasets/queries that might use default session (thus the 2nd session). Raul David Darlison wrote: I have an application that collects a file from a printer it converts the file empties the target table using EmptyTable, then runs a query to insert the file into the table. This works fine if I only run it once but as soon as I run it a second time I get a 11013 access error to the table when it comes to emptying the table again. I have tried everything, preparing & unpreparing the query, changing the PrivateDir of the session. Using the CreateTempTablesToDatabase on an engine but always it is the same. The application is running on a local machine, I have turned off the AV and the OS is XP with full Admin rights. |
Thu, Feb 21 2013 5:57 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | John
Is the query still open when you attempt to empty the file the second time? Roy Lambert [Team Elevate] |
Thu, Feb 21 2013 10:10 AM | Permanent Link |
Raul Team Elevate | On 2/20/2013 5:07 PM, John Comloquoy wrote:
> I'm using the "default" session and the first time round the table is emptied but flags Error #11013 on the second call after running a query on it. The table is still open by query would be my guess as well. > Setting the Exclusive property makes no difference. Setting exclusive requests exclusive access - DBISAM will throw and exception like you're seeing if it cannot not and that's how you handle this. There is no way to "force" exclusive mode. > Is there a way if finding out what is holding the table? I can write a work-around but prefer to get a better understanding of what's happening! (Win7//Delphi XE3//DBISAM v 4.34 Build 6). What is the KeepTablesOpen property set to in the DBISAMDAtabase ? Make sure it's False in this case to avoid any chance of table remaining open. You could also use the engine sessions option to list sessions and then for each session you can list databases. Finally on database level you can list DataSets to see what's still open. If you know for sure the only session is default one you start from it (skipping the engine part) and possibly you can do same from database side if you know you only have 1 database. Raul |
Fri, Feb 22 2013 3:22 PM | Permanent Link |
John Comloquoy | Roy Lambert wrote:
John Is the query still open when you attempt to empty the file the second time? Roy Lambert [Team Elevate] Thank you Roy and Raul for your help. Much appreciated. Yes the query was open but even when I close it the error is still flagged. I'm guessing that since the query is holding data from the table there must still be live references. Could this be the case? Raul, I'm using a single stand-alone database, but thanks for the clues provided. |
Sat, Feb 23 2013 4:32 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | John
>Thank you Roy and Raul for your help. Much appreciated. Yes the query was open but even when I close it the error is still flagged. I'm guessing that since the query is holding data from the table there must still be live references. Could this be the case? OK try unpreparing the query. That should release any of the tables still open. Roy Lambert [Team Elevate] |
Sat, Feb 23 2013 11:16 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | John,
<< Thank you Roy and Raul for your help. Much appreciated. Yes the query was open but even when I close it the error is still flagged. I'm guessing that since the query is holding data from the table there must still be live references. Could this be the case? >> Roy is correct - make sure a query is unprepared in order to close any tables referenced in the query. Referenced tables are opened during a prepare, and not closed until the query is unprepared/freed. Closing a query simply closes the result set, not the referenced tables. If you have any other questions, please let me know. Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Tuesday, September 17, 2024 at 04:19 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |