Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 4 of 4 total |
DBISAM Engine Error # 9480 The database <name> is full and cannot contain any more tables - Revisite |
Tue, Nov 4 2008 12:36 PM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 PM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 |
This web page was last updated on Friday, March 29, 2024 at 03:30 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |