Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 10 total
Thread Handle objects container capacity
Tue, Mar 28 2017 5:45 PMPermanent 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 PMPermanent 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 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate 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 AMPermanent Link

John Easley

I saw that.  Why is there a 512 limit?  
Wed, Mar 29 2017 10:51 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

John


>I saw that. Why is there a 512 limit?

Absolutely no idea

Roy
Wed, Mar 29 2017 5:54 PMPermanent Link

Raul

Team Elevate 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 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 PMPermanent 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 PMPermanent 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 PMPermanent Link

Raul

Team Elevate 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
Image