Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 9 of 9 total |
ElevateDB Error #9999 Handle objects container capacity (2048) exceeded |
Wed, May 4 2022 12:44 PM | Permanent Link |
Javierus CYBER Informatica Avanzada, S.L. | I'm quite sure it's a resource leak, 'cause it happens when the application has been running a bunch of hours
Is there any way I can get the number of handles in use at a given moment? a property or value somewhere? Thanks in advance |
Wed, May 4 2022 1:42 PM | Permanent Link |
Jose Eduardo Helminsky HPro Informatica | Javierus wrote:
<< I'm quite sure it's a resource leak, 'cause it happens when the application has been running a bunch of hours Is there any way I can get the number of handles in use at a given moment? a property or value somewhere? >> Usually it is. I do not know how can you get the number of current handles but you have to search code where a dataset (table of query) is created (in runtime) and not destroyed. var T: TEDBTable; begin T := TEDBTable.Create(self); // configure T T.Open; // Use table T end; T is not freed and keep then handle active at server side. I hope you find the place where the situation happen. Eduardo |
Wed, May 4 2022 5:40 PM | Permanent Link |
Raul Team Elevate | On 5/4/2022 12:44 PM, Javierus wrote:
> I'm quite sure it's a resource leak, 'cause it happens when the application has been running a bunch of hours > > Is there any way I can get the number of handles in use at a given moment? a property or value somewhere? I would simply log all active sessions and datasets and see if anything stands out that ought to be closed. Use the engine Sessions property to get all sessions and for each session you can list all Databases and for each one of those list all DataSets (which would be actual queries and tables). That should show anything open in the app and anything that is not closed. Raul |
Thu, May 5 2022 2:23 AM | Permanent Link |
Javierus CYBER Informatica Avanzada, S.L. | Hi all,
I should have added that the application can be compiled to run with BDE and with ElevateDB, and with the BDE there are no memory leaks, so there are no TxxSession, TxxDatabase, TxxTable, or TxxQuery unfreed Thet's why I was asking about how to get the EDB handle count at any given moment, so I could check it before and after some actions |
Thu, May 5 2022 7:29 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Javierus
I just did a search of this newsgroup and found a number of posts about this issue. Every time the answer is leaving things (tables, queries, sessions) open so I suspect it will be the same here. My bet, without knowing your code would be threads not being closed or leaving things open. Whilst there may be something in Tim's code to check for how many handles are on the go I don't know what it is but a quick google gave me https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-getprocesshandlecount However, something like: procedure TForm1.Button1Click(Sender: TObject); var Cntr: integer; SubCntr: integer; begin nlhTable1.Close; if nlhEngine1.Active and nlhSession1.Connected then begin for Cntr := 0 to nlhSession1.DatabaseCount - 1 do begin showmessage(nlhSession1.Databases[Cntr].Name + ' ' + inttostr(nlhSession1.Databases[Cntr].DataSetCount)); end; end; end; using your session would give you what you want - I think. It shows how many datasets for a session are active. Roy Lambert |
Mon, May 9 2022 1:59 PM | Permanent Link |
Javierus CYBER Informatica Avanzada, S.L. | Hi Roy,
Thanks for your interest, but I'm certain I'm not missing any dataset, database or session My application was developed for BDE, and there is a unit that implements the TxxTable, TxxDatabase, TxxQuery and TxxSession so a compiler switch decides if it inherits from BDE or ElevateDB components So the application itself knows zero and depends zero from BDE or ElevateDB components Wich means, it opens exactly the same datasets with both engines And with BDE it has zero memoty leaks; there are no Datasets lost anywhere |
Tue, May 10 2022 2:22 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Javierus
I understand what you're saying but its worth remembering that BDE and ElevateDB are different and operate in different ways. Can you produce a demo that causes the problem? If not its going on for impossible to provide any assistance other than to point out the culprit in previous occurrences. Roy Lambert |
Tue, May 10 2022 9:21 PM | Permanent Link |
Raul Team Elevate | On 5/9/2022 1:59 PM, Javierus wrote:
> Thanks for your interest, but I'm certain I'm not missing any dataset, database or session > > My application was developed for BDE, and there is a unit that implements the TxxTable, TxxDatabase, TxxQuery and TxxSession so a compiler switch decides if it inherits from BDE or ElevateDB components > > So the application itself knows zero and depends zero from BDE or ElevateDB components > > Wich means, it opens exactly the same datasets with both engines > > And with BDE it has zero memoty leaks; there are no Datasets lost anywhere It still looks like something is not being freed or closed in your code properly - 2048 is the limit for open statements per session so in this case start with query instances. Raul |
Fri, Aug 26 2022 6:24 AM | Permanent Link |
Javierus CYBER Informatica Avanzada, S.L. | Fixed it; it was my fault, but it was not on the application code itself, but on a component
No tables or queries undestroyed In case if someone is curious enough, I explain it (TL;DR) First a complain: it has been more difficult than it should have been due to the generic message: there are many resources handled by that Object Handles container class, so the only hint was the 2048 number, but more than half of those handle containers have that same limit: 2048 So first step was changing the constants to 2048+number, so I could get a more accurate hint No luck: same message Second step: added to the handle container object constructor a text tag (what it was used for) Weirdly, the messages where still the same So recompiled the server itself: Hit! Seems the client gets the message from the server; now I got to know that it was a problem with SessionManager.Cursors Easy peasy: it was a bug on my TEDBTable-derived component; it had overriden DestroyHandle, and was lacking a call to inherited DestroyHandle Fixed and fine |
This web page was last updated on Sunday, May 19, 2024 at 08:46 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |