Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 10 of 10 total |
Handle objects container capacity |
Tue, Mar 28 2017 5:45 PM | Permanent Link |
John Easley | dbisam engine: 4.43 build 1
I have a database that was previously storing tables with a id number. This database has thousands of tables. I have a program where I want to copy these tables to their own database based on their id number. I create the new directory. Once the appropriate table has been moved to its new location I then have DBISAMTable component that I set to this new database path and its table name. I check if exists and versionnum not equal to 4 and proceed to upgrading the table. It works great until about pass 1600 it bugs out with error: 'Handle Objects container capacity(512) exceeded' Can anyone elaborate on this error and why it is not beeing freed. |
Tue, Mar 28 2017 5:49 PM | Permanent Link |
John Easley | John Easley wrote:
dbisam engine: 4.43 build 1 I have a database that was previously storing tables with a id number. This database has thousands of tables. I have a program where I want to copy these tables to their own database based on their id number. I create the new directory. Once the appropriate table has been moved to its new location I then have DBISAMTable component that I set to this new database path and its table name. I check if exists and versionnum not equal to 4 and proceed to upgrading the table. The error comes up when it executes table.upgradetable. It works great until about pass 1600 it bugs out with error: 'Handle Objects container capacity(512) exceeded' Can anyone elaborate on this error and why it is not beeing freed. |
Wed, Mar 29 2017 3:22 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | John
Searching google/Elevatesoft newsgroups for the problem gives a few hits. This seems the most appropriate http://www.elevatesoft.com/incident?action=viewaddr&category=dbisam&release=4.33&incident=3566 Roy Lambert |
Wed, Mar 29 2017 10:32 AM | Permanent Link |
John Easley | I saw that. Why is there a 512 limit?
|
Wed, Mar 29 2017 10:51 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | John
>I saw that. Why is there a 512 limit? Absolutely no idea Roy |
Wed, Mar 29 2017 5:54 PM | Permanent Link |
Raul Team Elevate | On 3/29/2017 10:32 AM, John Easley wrote:
> I saw that. Why is there a 512 limit? Only Tim can answer for sure. There used to be an OS level limit for open files so i wonder if you're hitting that. Raul |
Thu, Mar 30 2017 11:31 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | John,
<< I have a database that was previously storing tables with a id number. This database has thousands of tables. I have a program where I want to copy these tables to their own database based on their id number. I create the new directory. Once the appropriate table has been moved to its new location I then have DBISAMTable component that I set to this new database path and its table name. I check if exists and versionnum not equal to 4 and proceed to upgrading the table. It works great until about pass 1600 it bugs out with error: 'Handle Objects container capacity(512) exceeded' >> How many database directories are you using ? The 512 is the limit on the number of open databases, so that's the limit you're hitting. To prevent this, turn this property off: http://www.elevatesoft.com/manual?action=viewprop&id=dbisam4&product=rsdelphi&version=XE&comp=TDBISAMSession&prop=KeepConnections and that should resolve your issue. Tim Young Elevate Software www.elevatesoft.com |
Thu, Mar 30 2017 4:12 PM | Permanent Link |
John Easley | Tim Young [Elevate Software] wrote:
>>How many database directories are you using ? The 512 is the limit on the number of open databases, so that's the limit you're hitting. We are migrating a project from 3.30 to 4. We have a 3.30 folder with thousands of files, so we are moving these files into their own directories. So, we wrote an migration utility that does the following: 1. Using a single TDBISAMTable (4.x) component (named tUpgradeTable) 2. Create a folder 3. Copy 3.30 tables to new folder 4. Set tUpgradeTable.Databasename to new folder path 4. Use tUpgradeTable component to Upgrade table from 3.30 to 4.x 5. Repeat Not using a session component or any other DBISAM component during this operation. Once the UpdateTable component has processed 512 files, it kah-booms on the 513th. John |
Thu, Mar 30 2017 8:19 PM | Permanent Link |
John Easley | Thanks Tim, Changing the keepConnections property to false in the session resolved the issue I was encountering. Question for you Tim. I saw the 512 is a constant you set when the session is created in 'dbisamen', Is there any kind of consequence if this value were changed to say a much larger number?
|
Thu, Mar 30 2017 10:19 PM | Permanent Link |
Raul Team Elevate | On 3/30/2017 8:19 PM, John Easley wrote:
> Thanks Tim, Changing the keepConnections property to false in the session resolved the issue I was encountering. Question for you Tim. I saw the 512 is a constant you set when the session is created in 'dbisamen', Is there any kind of consequence if this value were changed to say a much larger number? Sounds like you're fighting the product - why would you want thousands of dynamic database instances hanging around ? Using an actual database component might solve this as well since it would prevent auto-creation. Raul |
This web page was last updated on Tuesday, April 23, 2024 at 08:10 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |