Johan


Why not send your test app (compiled exe and source) to Tim so he can see exactly what you're talking about?

Roy Lambert [Team Elevate]

Johan,

<< Yes I know, but I work C/S and the process I meant is the process on the
Client workstation. The extra memory that seems to be allocated is what I
see on the server machine where DBSRVR resides. If I execute the described
process once on the client workstation then I measure a little bit of memory
remaining allocated on the server. When I execute this process on the client
workstation n times the result of allocated memory on the server is n times
as large. During execution of the one single process on the client
workstation it does not matter how many MEMORY\ tables I CREATE or DROP -
the remaining allocated memory on the server is always the same. Only after
restarting the DBSRVR process on the server the allocated memory is freed.
At least that is what FastMM or VMMap tells me. >>

Resolved via email:

I was finally able to reproduce what you were describing using your project.
The key item was the new process execution, and the cause of the memory
consumption was the creation of a new in-memory lock file per process.  The
in-memory lock files are named per process, so they were being created for
each process but never freed, and each would allocate a 64k block for the
memory file.

I've got a new build going out today that will fix this.

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com