Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 4 of 4 total
Thread DBISAM Engine Error # 9480 The database <name> is full and cannot contain any more tables - Revisite
Tue, Nov 4 2008 12:36 PMPermanent Link

"B Miller"
This topic has been discussed before at length and I thought I had the
solution but here's another situation that I believe is causing this error.

Temporary tables are created, anywhere from 1 to 6 for report creation.
They are currently named with a prefix and combined with a unique counter.
I cannot use memory tables because the report(s) may contain every record or
just a partial set.

So, here's my dilema.  While a report is being generated, another process
may occur, such as updating or inserting info into one of the permanent
tables.  When the info is updating in a transaction, will the dbisam.lck
file read the directory and add all the tables?   During our testing, we
haven't been deleting the temporary tables but started opening them
exclusively.  With one test user, they received the error (#9480).  I
reminded them to delete the dbisam.lck file, so they did.  They ran one
report and received the error.  It is possible that we missed an exclusive
in the sql but I think the update of their login information filled the .lck
file with every table in the data directory.  We deleted all the temporary
report files in the data directory and all is well, for now.

If during the course of day-to-day operations, temp files are created and
deleted, will they be added to the lck file while another user is updating
other tables if they exist?  They will be deleted when the report is
finished but they will exist for a while at the time others are doing their
work.  Can this be avoided by using 'Start Transaction With <tablelist>' by
including only the tables we want to be locked?

Using DBISAM 4.26b3

Bill

Tue, Nov 4 2008 3:59 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Bill,

<< If during the course of day-to-day operations, temp files are created and
deleted, will they be added to the lck file while another user is updating
other tables if they exist?  They will be deleted when the report is
finished but they will exist for a while at the time others are doing their
work.  Can this be avoided by using 'Start Transaction With <tablelist>' by
including only the tables we want to be locked? >>

No, that won't help.  Are you creating the temporary tables in the database
directory ?  If so, then don't.  Use the Windows temporary files directory
instead.

Also, as long as you are opening up the tables exclusively, then there
shouldn't be any issue with the .lck file.  Are you creating indexes on any
of the temporary tables ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tue, Nov 4 2008 4:13 PMPermanent Link

"B Miller"
> Bill,
>
> << If during the course of day-to-day operations, temp files are created
> and deleted, will they be added to the lck file while another user is
> updating other tables if they exist?  They will be deleted when the report
> is finished but they will exist for a while at the time others are doing
> their work.  Can this be avoided by using 'Start Transaction With
> <tablelist>' by including only the tables we want to be locked? >>
>
> No, that won't help.  Are you creating the temporary tables in the
> database directory ?  If so, then don't.  Use the Windows temporary files
> directory instead.

It is a C/S application so I can't really use the windows temp.  From your
response, does that confirm that an update to a shared, permanent table will
cause all the temps to be added to the lck file?  I guess I could create a
TempReport database and have all the tables created there.  Since I already
have those accessed exclusively, the lck file in TempReport db should never
be outgrown.  The tables in the regular database will never have the
opportunity to be cluttered with the temps.  Right?

>
> Also, as long as you are opening up the tables exclusively, then there
> shouldn't be any issue with the .lck file.  Are you creating indexes on
> any of the temporary tables ?
There are 'order by's with the 'select into' but no separate 'create index'.

Bill

Wed, Nov 5 2008 12:52 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Bill,

<< It is a C/S application so I can't really use the windows temp. >>

Can't you use the temp directory for the Windows server ?

<< From your response, does that confirm that an update to a shared,
permanent table will cause all the temps to be added to the lck file? >>

No.  And update alone won't do it.  However, if you delete the dbisam.lck
file, and then access the database directory, then all tables with the table
extension will be added to the dbisam.lck file.

<< I guess I could create a TempReport database and have all the tables
created there.  Since I already have those accessed exclusively, the lck
file in TempReport db should never be outgrown.  The tables in the regular
database will never have the opportunity to be cluttered with the temps.
Right? >>

Correct, provided that all temporary tables are being opened exclusively.

<< There are 'order by's with the 'select into' but no separate 'create
index'. >>

Okay, good.

--
Tim Young
Elevate Software
www.elevatesoft.com

Image