In a few words:

What am I doing wrong ?

And what do I have to do to find the source of this problem ?

Jose

>And what do I have to do to find the source of this problem ?

How about a few more words first. From your post I have absolutely no idea what you're talking about.

Roy

Roy Lambert wrote:

<<
How about a few more words first. From your post I have absolutely no idea what you're talking about.
>>

Ok. One of my customers are receiving the error "Handle objects container capacity (2048) exceeded". I can´t reproduce the problem here in my office and I don´t know where should I start searching. The routine have table access and query access and I have double checked the code without to be sure what to look for.

The application is running in C/S and I am using ElevateDB server in the last version 2.28 build 7.

Eduardo

On 11/8/2018 10:46 AM, Jose Eduardo Helminsky wrote:
> In a few words:
> What am I doing wrong ?
> And what do I have to do to find the source of this problem ?

First guess is that you are leaking sessions (or not closing sessions so
app keeps building up sessions.

Places i'd check
- does ebd server show lot of sessions when this happens ?
- check your app and see if there is any chance you are not closing
sessions and creating new ones (for example log the EDBEngine
SessionCount and see what it says in the app)

Raul

Jose


I searched my local copy of the newsgroups and found a thread back in 2013
---------------------------------------------------------------------------------------------------------------------------------------------------
From: Hedley Muscroft
Subject: ElevateDB Error #9999 Handle objects container capacity (4096) exceeded
Date: Tue, 17 Sep 2013 12:19:51 -0400
Lines: 5
Message-ID: <E39EEC53-BE6E-4375-9AEE-2AFCDED9E081@news.elevatesoft.com>
Newsgroups: elevatesoft.public.elevatedb.general
Path: www.elevatesoft.com


We've got a customer who has received this error a number of times - any idea what it means please and how to resolve it? (Have tried REPAIR TABLE etc.)

Thanks,

Hedley
------------------------------------------------------------------------------------------------------------------------------------------------

Ultimately that was found to be

------------------------------------------------------------------------------------------------------------------------------------------------
Thanks Tim - I think I may have found the issue...

I actually implement my own layer of reference-counted EDBConnection caching in my application.

When I first started developing with EDB C/S, all my customers kept getting #300 Session Lock errors when connections were being used across multiple threads. The caching layer silently creates a new EDBConnection object if/when it hits a "#300 session lock" from a secondary (non-UI) thread and then disposes of the connections when not in use.

Anyway, I just found a bug in one place where the connection was not being de-referenced. It's hard to believe that this would end up hitting the 4096 limit, but I guess if the app is running for days, that could happen! :-/

My next update will fix that issue, so I'll let you know if it re-occurs.

Many thanks to everyone for their help!

Kind Regards,

Hedley
------------------------------------------------------------------------------------------------------------------------------------------------


Probably no help but worth a look.

Roy Lambert

Everyone

I think this is not my case:

1) There are only 3 (three) sessions when the problem appears

2) There are only one session involved in the situation.

3) BTW, the error did not happen again but I did nothing to "solve" the issue.

The only thing I would like to know is: Only many sessions could do this error ?

Thanks

Eduardo

Jose


How do you know its ElevateDB that's teh source of the error - it might be a third party component not giving its handles back.

C/S is a bit tricky but, if you have the source, you could try compiling with FastMM4 in full debug mode - its generally good at spotting leaks.

Roy Lambert

On 11/12/2018 3:57 AM, Jose Eduardo Helminsky wrote:
> 1) There are only 3 (three) sessions when the problem appears

Where are you seeing the 3 - on dbsrvr server or in app ?

if on server then you're only seeing active (or recently active)
sessions so i'd try the app session count as well just in case.

> The only thing I would like to know is: Only many sessions could do this error ?

Tim is only one that would truly know the answer so it might be
worthwhile to email support so you get his direct attention.

Raul

Eduardo,

<< In a few words:

What am I doing wrong ?  >>

2048 is the limit for open statements/procedures per session, so more than likely you're opening/executing TEDBQuery or TEDBScript/TEDBStoredProc components and not closing/freeing them.

Tim Young
Elevate Software
www.elevatesoft.com