Rick,

>Thank you again for your responses. I had originally assumed that reassigning x or .null."ing" it out would destroy any contained objects, but when I was loosing all this memory with each pass through I tried everything. It is possible that I did do something like y = x.oSomething, but y would have been in a lower level and lost when I returned to the main application level.

Yes, if y was a local memvar when it goes out of scope, or is released (you don't have to explicitly .null. it) the object it was referencing will have it's count reduced and allow it to destruct if the count hits zero.

Do you use PEMSTATUS() and/or GETPEM()? They have a nasty side effect of leaving internal object references that we have no control over. It is a problem when two or more of them are used in an expression or IF. The workaround is to use separate assignments for each call:

x1 = pemstatus()
x2 = pemstatus()

if ( x1 and x2 )
endif

>We also discovered the problem with the VFP5 .TLB and also use InvokeHelper(). The VC++ program basically instantiates the VFP Server and executes a couple of methods in it. The VC++ client handles telephone traffic, modem communications, and passes information received to the VFP Server. VFP Server accesses tables, manipulates data, and basically returns BOOL back to VC++. The only reference VC++ client has is to the server object. I will continue to look at this -- I must have done something so stupid that I can't even see it, but it permeated all of my COM servers, so at least I am consistently stupid. Reuseing the objects, as I said earlier, solved the problem.

That's the same kind of thing I'm doing. The VC++ app is doing serial communication to devices on a RS485 network, it calls the VFP server to put the data into tables. I return an int condition code so that we can handle possible errors during the table writes.