Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 9 of 9 total |
Handle objects container capacity (2048) exceeded |
Thu, Nov 8 2018 10:46 AM | Permanent Link |
Jose Eduardo Helminsky HPro Informatica | In a few words:
What am I doing wrong ? And what do I have to do to find the source of this problem ? |
Thu, Nov 8 2018 10:52 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Thu, Nov 8 2018 10:59 AM | Permanent Link |
Jose Eduardo Helminsky HPro Informatica | 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 |
Thu, Nov 8 2018 11:53 AM | Permanent Link |
Raul Team Elevate | 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 |
Fri, Nov 9 2018 2:50 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Mon, Nov 12 2018 3:57 AM | Permanent Link |
Jose Eduardo Helminsky HPro Informatica | 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 |
Mon, Nov 12 2018 9:42 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Mon, Nov 12 2018 9:57 AM | Permanent Link |
Raul Team Elevate | 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 |
Fri, Nov 16 2018 12:49 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
This web page was last updated on Thursday, May 23, 2024 at 07:54 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |