Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 5 of 5 total
Thread 9480 - database is full and cannot contain any more tables
Wed, Aug 15 2012 9:03 AMPermanent Link

John Easley

I'm migrating an app from 3.26 to 4.33 B4 and came across this.  I have a folder that contains 10,000+ import tables.  These tables are used once for importing, then archived, but cannot be deleted.

If the database folder contained 10,000+ folders instead of 10,000+ tables, would this error still bubble up?

I'm thinking I can place these import tables into folders based on some sort of date, like \Aug-2012\import1.dat etc.. and I want to make sure there are no limitations before I commence.

Also, why does this limitation exist in 4.33 and not 3.26?
Wed, Aug 15 2012 10:24 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

John

>Also, why does this limitation exist in 4.33 and not 3.26?

Easy bit first - Tim changed the way DBISAM managed locks and there is a limit on the number of tables it can handle.

I'm guessing that you're crating lots and lots of temporary tables and these are what's filling the lock system up. Its a long time ago but I seem to remember the solution is to set the temporary tables to exclusive before opening them. This means they never get registered in the lock system so everythings ok.

The alternative is to manually delete the lock file every so often.

Roy Lambert [Team Elevate]
Wed, Aug 15 2012 1:49 PMPermanent Link

John Easley

Roy Lambert wrote:

>I'm guessing that you're crating lots and lots of temporary tables and these are what's filling the lock system up. Its >a long time ago but I seem to remember the solution is to set the temporary tables to exclusive before opening >them. This means they never get registered in the lock system so everythings ok.

Like I said, I have 10,000+ archive tables, not temp tables.

Since there isn't a TDBISAMQuery.Exclusive property, how do I go about handling queries?

John
Thu, Aug 16 2012 4:39 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

John


There is a post from around 2004 (80750830-DA3B-48C5-9A7B-7FF671C7AB0E@news.elevatesoft.com) where Tim makes the following comment:

You're including the EXCLUSIVE flag in your SQL opens also ?

and give the following example:

The problem is with your INSERTS.  You need this instead:

INSERT INTO "Transfers" (OID, TransferedToID, TransferedFromID,
TransferedByID, [Transfer #], [Manual Transfer #], [Date Transfered],
Transfered, Void, Posted, Notes, [Last Modified])
SELECT OID, TransferedToID, TransferedFromID, TransferedByID, [Transfer #],
[Manual Transfer #], [Date Transfered], Transfered, Void, Posted, Notes,
CURRENT_TIMESTAMP
FROM "\MEMORY\Transfer_511B4B2EE8D2490CAF43FBC1592B8C25" EXCLUSIVE;

INSERT INTO "TransferDetails" (OID, TransferID, MatrixID, Qty, [Qty
Shipped], [Last Modified])
SELECT OID, TransferID, MatrixID, Qty, [Qty Shipped], CURRENT_TIMESTAMP
FROM "\MEMORY\TransferDetail_1B272174BF5B44299508C8D79D0D1196" EXCLUSIVE;

and from a post in 2008

<< Is the entry in the lock file related to the name of the table? >>

Yes.

<< In other words: would creating and deleting a table with the same name
over and over again increase the number of lock file entries? >>

No.



Roy Lambert [Team Elevate]
Mon, Oct 1 2012 10:37 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

John,

<< If the database folder contained 10,000+ folders instead of 10,000+
tables, would this error still bubble up? >>

No, you would be fine then.  The issue is that the first time the dbisam.lck
file is created (hidden), all .dat table files in the same database
directory are added to the lock file, so moving them into subdirectories
should divide them up enough to prevent the issue.

The max number of tables that can be in a single database directory in 4.x
is 4096.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com
Image