Typical cause is dangling object references. You want to make sure that as each object closes that all references to that object are both set to null and released from memory.

There are a number of methods for managing object references. There are several articles about such reference management mechanisms. There are some rules to follow to this end.

1. Local References are best. When my method code needs an object reference, I set up a local variable for it (i.e., loMyObject). I then have what I call Query methods that now how to fetch object references for me. Thus, after declaring LOCAL loMyObject, I follow that up with loMyObject = THIS.qoMyObject( ). The query method can now be called from anywhere in my class object, or by any other class that has a reference to the class with the query method, and obtain a reference to MyObject from the query. Finally, when the local method code is done the loMyObject will be released as the method loses focus (poor man's garbage collection). If it makes you feel better, you can use a RELEASE loMyObject just before your RETURN instruction.

2. When a more global reference is needed, I prefer to store them in an array or as what I call an "instance property". Thus, I might have a property named ioMyObject. The property ioMyObject will have two corresponding methods:

qoMyObject( ) --> object
cmSetMyObject(toMyObject: object)

The qoMyObject method will have code like:

local loMyObject
loMyObject = THIS.ioMyObject
return loMyObject

The cmSetMyObject method will have code like:

lparameters toMyObject
assert type("toMyObject") == "O" ;
message "require failure: Expected toMyObject to be data type object."
THIS.ioMyObject = toMyObject
return

This works best for managing objects that you know about at design time. However, there are times when you are adding objects at run-time and AddObject is the right thing to do. Regardless, the object references need to be managed and never assumed. It is the "assumed" management method that will (from time to time) leave a dangling reference that will produce a C000005 error in VFP.

The reason for using either known reference instance variables or arrayed lists of object references is that a destroy object reference management scheme can take advantage of that specific knowledge and release the references before they become "unknown" and dangling.

One final note. It is not the objects themselves that need to be released so much as the references. When VFP shuts down it will destroy each object in memory on its way out. References, however, are the problem children that need to be managed.

Hope this helps.

Larry