>Any other observations that might help explain this?
>>
>>It's hard to say without seeing the code. Are any objects created with addobject or createobject? or are the all added via the designer at design time?
>>What is the baseclass of FrmPages? I assume pgfBase is your base pageframe class.
>>
>>Is there a difference if you close the form with the upper right hand x versus closing it with a close button?
>>
>>Is there any special code in the destroy of your objects?
>
>There are no objects created with addobject or createobject.
>frmPages is a subclass of frmBase (my base form class) and has an instance of pgfBase (my base pageframe class) on it.
>My pgfBase has a property nPageCount and PageCount=10. pgfBase.Init() does a RemoveObject of all pages over nPageCount (so I can set properties of all the pages in pgfBase in the designer and just remove the ones I don't use in the particular form).
>My frmBase.Destroy() has a call to a prg file that closes all the files in the datasession (because it doesn't always close the datasession on releasing the form. Now that I think about it, that kind of supports your idea that something is still in memory. The datasession is not being removed possibly because there is still something in memory somewhere.
>
>I have a similar (maybe) problem with 1 or 2 of my base classes. I cannot modify txtBase after running any forms (but I can modify a subclass of txtBase). There I get a message saying that I cannot modify a class that's being used. For some reason when the form disappears, the txt object doesn't, but it only affects txtBase not any of the subclasses. Maybe this is tied in with the problem with pgfBase.

Is there any property(s) that you use that are object references? If so, something might not be getting released properly. Your data environment should shut down. Do you have a DODEFAULT() in the Destroy? You shouldn't have to manually close your tables. Why this is necessary is an indication that something is being destroyed properly. Now, what can it be?