Peter,

This is definitely something weird and different.  I'm testing with 2000
connections, and while the memory does go up, tracing through the
destruction of the the entire set of engine objects and allocations, etc.
does not result in any drop in the 28 megs of virtual memory that is left
according to the task manager.  Furthermore, FastMM is not reporting any
leaks, of course, so it isn't a traditional leak at all.  So, it may be
something external to the engine.  I'm going to try some more things and see
what else I can find.  Right now I'm running the server with a UI, so I'm
going to try it without a UI.

--
Tim Young
Elevate Software
www.elevatesoft.com

Peter,

It's like I thought - it's something with the external modules.  I'm
investigating now to see what the issue is.  If you remove all external
modules from the configuration path, you will see the memory hold steady.

--
Tim Young
Elevate Software
www.elevatesoft.com

Peter,

<< It's like I thought - it's something with the external modules.  I'm
investigating now to see what the issue is.  If you remove all external
modules from the configuration path, you will see the memory hold steady. >>

Okay, here we go:

Do any of the external modules that you're using reference the Forms or
Controls units, or any units that cause these units to be referenced ? If
you do, then you'll experience leaks that are coming from the VCL that will
affect your application.  These are *not* coming from ElevateDB.  I just so
happened to have an external module in my test config path that had a
reference to the Dialogs unit for a debugging ShowMessage call in it, and
that showed the issue.  Once I removed the Dialogs reference, the issue goes
away.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,
I am sorry.
I broke rule #1 in email communication: "never try to make a joke - at least not  in a language which you dont know perfectly".
Working with you for almost 10 years - starting with dbisam 1 - I always concidered your support to be among the best.
Sorry again.
Peter

>>
>>What is the purpose of this comment, exactly ?  Have we ever responded to
>>you in a fashion that would warrant this type of comment ?  We treat you
>>with prompt and respectful answers, and we expect the same in return.
>>Implying that we would even consider giving you such a response is
>>completely dishonest.  Never in our 10 years of doing business have we ever
>>told someone to get the source code and find the bug for themselves.
>>
>>And for the record, I did not tell you that you had to upgrade from V1 to V2
>>to get a fix for this.  What I said was that 2.x is getting priority for
>>fixes ahead of 1.x.  I am still going to issue a 1.x update to fix this
>>issue with 1.x, as I indicated in my response to you.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Peter,

Just a tip. Use a smiley like or at the end of the sentence just =
to make sure (almost) everybody understands it is indeed a joke - it =
does make a big difference.

Best regards,
Fons

Tim
I didn't know there was a leak in Dialogs - do you know what it was and which version?

Roy Lambert

Peter,

<< I am sorry.
I broke rule #1 in email communication: "never try to make a joke - at
least not  in a language which you dont know perfectly".
Working with you for almost 10 years - starting with dbisam 1 - I always
concidered your support to be among the best. >>

No need to apologize if that was your intent.  A simple explanation is
enough, thank you.  As Fons indicated, a at the end would have made the
difference.

At any rate, in addition to my other post, the other thing that can cause it
is using D5 to build the external module.  D5 required a Forms unit for
custom modules, which is what we're using for our TEDBExternalModule,
TEDBWordGeneratorModule, and TEDBTextFilterModule components.

Are you building the external module using D5 ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

<< I didn't know there was a leak in Dialogs - do you know what it was and
which version? >>

It's not in Dialogs - it's in the Forms unit in the
initialization/finalization, AFAIKS.  At least with D7 that I was testing
with.

Also, our DBISAM migrators are clean, but the BDE and ADO migrators are
leaky also due to the fact that they're referencing some leaky units.  I
didn't track these down, but I would assume that they're referencing the
Forms unit or there's an issue with the DLLs that they're loading.

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

That should be AFAICS.  Last time I checked "can" was not spelled with a
"k".

--
Tim Young
Elevate Software
www.elevatesoft.com