Matthew,

<< Can I ask why deleting the file doesn't delete the lock file entry? I
guess there must be a good reason, and thinking about it I don't think I'll
be affected by this, but it seems odd. >>

The position of the table determines the lock slot, and so the positions
cannot be shifted while the database tables are in use.  Compacting the slot
positions when a table is dropped would cause different sessions to use
different lock slots.

--
Tim Young
Elevate Software
www.elevatesoft.com

TVM.

/Matthew Jones/

Issue:

<<If I have an application where I create and delete one table, that application will
result in an #9480 error after running it 4096 times >>



Question:

Is that 4096 times in one session of my application, or over the lifetime of my DBISAM
database?


Does this issue apply only to tables, or does it also apply to other db objects such as
indexes (e.g. dropping and recreating indexes) ?


Thanks!!!

Sam


From my recollection its 4096 tables regardless of session or process. I don't think indices count.

Roy Lambert

> << I must be misunderstanding this. Are you telling me that if I have
> an application where I create and delete one table, that application
> will result in an #9480 error after running it 4096 times? >>
>
> Yep.  Although, the issue is that the table is opened non-exclusively
> that causes the lock file entry.  If you are creating and deleting
> temporary tables, then setting Exclusive=True when opening the table
> will prevent it from being added to the lock file.

Tim,

I've been delving into my code to solve the #9480 error. I've done this
by first "filling up" the .lck file, and then running my testsuite.

At the moment I'm seeing two problems:

1. I've included the "exclusive" clause in all the SQL where
appropriate. However, there seems to be no "exclusive" clause for the
"alter table" command (I use this to add a primary index to a temporray
table). The "alter table" command does generate the #9480 error, so I
guess it's adding an entry to the .lck file. Is there a way around this?

2. Not all temporary tables are meant for exclusive use. How would I
solve the problem where I need a temporary table that should be
accessible to more than one user?

TIA,
Robert.

--
Robert.

Whatever you are, be a good one
===
http://robertcram.blogspot.com

Sam Jones wrote:

> Issue:
>
> <<If I have an application where I create and delete one table, that
> application will result in an #9480 error after running it 4096 times
> >>
>
> Question:
>
> Is that 4096 times in one session of my application, or over the
> lifetime of my DBISAM database?
>
>
> Does this issue apply only to tables, or does it also apply to other
> db objects such as indexes (e.g. dropping and recreating indexes) ?


That is 4096 times over the lifetime of your DBISAM database (unless
you disconnect all clients and delete the .lck file). I don't know
about indexes.

--
Robert.

Whatever you are, be a good one
===
http://robertcram.blogspot.com

Robert

. I've included the "exclusive" clause in all the SQL where.
>appropriate. However, there seems to be no "exclusive" clause for the
>"alter table" command (I use this to add a primary index to a temporray
>table). The "alter table" command does generate the #9480 error, so I
>guess it's adding an entry to the .lck file. Is there a way around this?

Any table restructuring requires exclusive access to the table hence no specific parameter. I can't understand why it would need to add an entry to the .lck at all.

>2. Not all temporary tables are meant for exclusive use. How would I
>solve the problem where I need a temporary table that should be
>accessible to more than one user?

From memory what I did was "reuse" table names where I couldn't make them exclusive. Until I encountered this feature all memory tables were created with unique names based on GetTickCount. Afterwards a lot were still like that but others had standard names.

Roy Lambert

Roy Lambert wrote:

> Any table restructuring requires exclusive access to the table hence
> no specific parameter. I can't understand why it would need to add an
> entry to the .lck at all.

You are right of course. That certainly explains why I couldn't find
the "exclusive" clause for "alter table"

Now the only mystery that remains is the #9480 error it generates. I
hope Tim can shed some light on this.


> From memory what I did was "reuse" table names where I couldn't make
> them exclusive. Until I encountered this feature all memory tables
> were created with unique names based on GetTickCount. Afterwards a
> lot were still like that but others had standard names.

But the problem is that even having one temporary table with a unique
name left would eventually (if you run the application often enough)
result in a #9480 error. How did you solve that?


--
Robert.

Whatever you are, be a good one
===
http://robertcram.blogspot.com

Robert

>But the problem is that even having one temporary table with a unique
>name left would eventually (if you run the application often enough)
>result in a #9480 error. How did you solve that?

I'm pretty sure that the solution was that only the ones I could open exclusively had unique non-reusable names.

Its a bit kuldgy but how about creating a table - two fields name (unique string) and inuse (boolean). Create say a couple of thousand entries. Whenever you need to create a temporary table grab the first non-inuse name. When finished reset inuse to false.

I don't know how many may be needed spread across the users of an installation of your app but combined with setting exclusive it might work.

Roy Lambert

Sam,

<< Is that 4096 times in one session of my application, or over the lifetime
of my DBISAM database? >>

The latter - database.

<< Does this issue apply only to tables, or does it also apply to other db
objects such as indexes (e.g. dropping and recreating indexes) ? >>

Just tables.

--
Tim Young
Elevate Software
www.elevatesoft.com