>Jim,
>I am having a similar problem that I have posted on the UT and now "dialoguing" with Erik Moore ( see Data not UNLOADING on RELASE of Form) I go as far as explicitly releasing my tables since the unload event won't and I still get a GPF on a SQLCANCEL() function before QUITting VFP.
>
>Any help is appreciated.
>
>Michael Haggerty
>amkhag@erols.com
>haggertm@pwba.dol.gov
Michael,

Your problem hss nothing to do with files being closed. When the form gets fully destroyed its data session will also be closed down automatically.

The problem is that there is something somewhere that is holding a reference to either the form itself or any one of the objects inside of the form. This external object reference is preventing the referenced object from being destroyed and therefore also stopping the for from being destroyed.

Finding these references can be a bear, especially if you don't know when or where you created it (like using a framework you don't fully understand, or something like that).

Just ofr an example of an external object reference, which may help you in tracking down your problem. let's imagine I have a form named Form1 that needs to run a form named form2. Now in a method of Form1 I have this code;

THISFORM.SubForm = CreateObject("Form2")

SubForm is a custom property of Form1 and it now holds a reference to the Form2 object. Now in Form2 I have a button that says THISFORM.Release() in its Click. When I click that button the form's destroy will execute but the Unload will not execute because the SubForm property of Form1 is holding an external reference to the Form2 object.

If, after I clicked the button in form2, I somewhere say Form1.SubForm = .NULL., then suddenly Form2's UnLoad will fire and its tables will get closed and all will be well.

Here's another scenario that will cause the same problem with Form2 would be;

PUBLIC oForm
DO FORM Form2 NAME oForm LINKED

In this case the public variable oForm is referencing the Form object and clicking the button will fire the form's release and attempt to destroy the form object, but that nasty public variable is still out there referenceing the form and thereby preventing the object's destruction. Until that variable is either reassigned a different value or released the form cannot go away.

Hope this is helpfull in getting looking in the right places for the solution to your problem. Closing the tables is not going to do you any good at all.