>>>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