>>>>What did you find out after implementing this trick?
>>>>BTW, adding call to this procedure from multithreaded VFP dll in each 50 iterations made no effect in our case.
>>>
>>>My vague memory is that Bernard's trick didn't really help, though I don't remember for sure.
>>>
>>>I added code to the app that lowers its overall memory load by doing some garbage collection and so forth. (We have a bunch of collections that tend to grow and grow and grow.) We got it down to the point that it hasn't been a problem for the customers.
>>>
>>>Tamar
>>
>>The class I'm working on does not use collections at all. It uses a few arrays and it also passes big strings in and out. Also it calls sqlexec (as a method) in a loop. I'll try to comment sqlexec calls and see if it helps to memory. If yes, then I have a plan of how to re-write this dll to use local cursor. If not, then I think the path should be to re-write this dll in .NET
>
>
>No idea whether this will help
>
>Years ago, I had a class method that had a local array with objects in it. The objects held references to other objects, etc - a whole hierarchy
>
>The class called that method which allocated a bunch of objects (with the hierarchy beneath them) . The objects were stored in a local array
>After the method call other methods were called and it was quite cpu-intensitive
>
>
>What I found is that the destroy event of the objects in the array did not fire upon exit of the method, but later when foxpro encountered an idle state to do the garbage collection
>
>The only way I found to have the destroy fired was to (1) release the array or (2) store null to array prior to exiting the method
>
>I am now entering 'speculation' mode
>
>(1) Foxpro does not perform garbage collection until it finds time to do it (idle state or perhaps doevents)
>(2) It may be the case here especially if strings are stored in a local array
>
>
>Try to release all local variables (certainly the arrays and the big strings) of the method prior to its return

Gregory,

please pardon me for jumping in with an unrelated question. Could this delayed garbage collection that you describe, be the reason why the "right way" to release an object, is to first set the reference to .null. and then release it? IOW, could it be that setting the reference to .null. forces VFP to do this garbage collection?