Hi Jason,

Thanks for the ideas. It turns out that at least in the example I gave, I'm encountering a "feature" of VFP. According to message #778414, if two different classes inherit from the same parent class, and you instantiate each, a copy of each is cached in memory. In that situation, you cannot edit the base class since the derived classes are still in memory.

The solution is to clear the classes explicitly.

Now the question is - is this causing my performance hit, or do I have another issue altogether! Man is this ugly.

Thanks again, and if anything else hits you, please let me know.

>David,
>When I instantiate my kBizObj subclasses in the command window, I don't see the same problem -- after releasing them I can modify without getting the prompt to remove the class from memory.
>
>Is this happening with both objects? Are you instantiating other objects in the Init() perhaps? Try using the debugger and search the properties of the objects to see if there are any object references still "alive" that are preventing the object from destroying properly.
>
>---J
>
>>Hi Jason and everyone else,
>>
>>Thanks for the thoughts.
>>
>>There are no indications of a dangling object reference that I can find. David Frankenbach has a tool to find them, and it is not finding them. However, I'm pretty convinced that there is some sort of wierd memory issue going on. I've been running dozens of tests, and I think there's something funky going on with MM. Here's where I'm at:
>>
>>class1 is a direct subclass of kBizNess
>>class2 is a direct subclass of kBizness
>>
>>Neither has a dataenvironment defined. They are both just bare bones subclasses.
>>
>>Do the following:
>>

o1=create('class1')
>>o1.release()
>>

>>Everything OK there.
>>
>>But do the following:
>>

01=create('class1')
>>o2=create('class2')
>>o2.release()
>>o1.release()
>>

>>
>>Seems to work OK, but now try the following:
>>
>>modify class kbizobj of kbizness
>>
>>VFP says that kbizobj is in use, would you like to remove it from memory. Why the heck is it in use?!?
>>
>>I'm going to keep on testing to try to nail down what's happening.
>>
>>Just FYI, I'm trying this in both VFP 8 and VFP 7.
>>
>>Any additional thoughts from anyone are appreciated!!!
>>
>>
>>
>>>Hello David,
>>>Yes, dangling reference issues can be maddening to uncover. I know there used to be a post here about a utility to show dangling references, but I couldn't seem to find the thread anymore.
>>>
>>>There are a couple ways to determine if what you're dealing with is, in fact, a dangling reference. One is that the private datasession will not go away due to the continuing object reference existence. The other is that your form may not completely destroy, leaving it in some "undead" state where it still displays on the screen yet doesn't respond to mouse clicks, etc.
>>>
>>>If your private datasession is still hanging around, you may be able to determine which of the objects (or at least narrow your choices) is the culprit by looking at the remaining views. The objects that destroyed properly should have closed "their" DE's views.
>>>
>>>Calling a business object's Destroy() method clears the reference, so once you narrow the list, try explicitly calling that method for one of the remaining objects. If that suddenly clears the problem... well, I'm sure you can guess the rest!
>>>
>>>Hope that sets you on the right path
>>>---J
>>>
>>>>Hi All,
>>>>
>>>>I have a form with a 4-page pageframe, using a private datasession. In most cases, there are about 10-15 views open - most for lookup and populating lists, 4 for writing to data. Most times, the form works fine.
>>>>
>>>>However, in one situation, I open about 3 dozen more views. In particular, when deleting an object, I create a very deep containership hierarchy of business objects. Each business object checks it's contained objects to be sure that the deletion is OK to run. These objects then check their contained objects, and so on. This results in literally dozens of views being opened. The contained objects don't instantiate until needed (i.e. for the deletion). (I'm using Mere Mortals, and Mere Mortals Business Objects.)
>>>>
>>>>After performing this deletion, performance slows to a crawl, and the only way to restore it is to exit out of the app (or VFP) entirely.
>>>>
>>>>My initial thoughts were a dangling object reference, and I still leave that open as a possibility, but I can't find it anywhere.
>>>>
>>>>Does anyone else have any other ideas? Alternatively, any thoughts on how to find a dangling reference?
>>>>
>>>>I'm thinking that the RefBizObj collection of the form is screwing things up, but I can't see where. It does not seem to like interacting with each bizobj's RefBizObj collection when on a form.
>>>>
>>>>Thanks,
>>>>
>>>>David
>>>>
>>>>(I'm also posting this message under TroubleShooting).