Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 8 of 8 total
Thread 11013 Access denied
Wed, May 30 2012 12:06 PMPermanent 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 PMPermanent Link

Raul

Team Elevate 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 PMPermanent 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 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate 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 AMPermanent Link

Raul

Team Elevate 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 PMPermanent 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 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate 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 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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
Image