>>>>It might, depending on where the code to call SQLDISCONNECT() is. I'd make a SWAG saying that if it's in the QueryUnload or maybe Destroy method it might. The only way to know for certain would be to test it.
>>>
>>>This is true. I tested this using an object (could be your global application object). The Destroy event does fire when the application is shut down using the WM_CLOSE message.
>>
>>Thanks for the info, Larry. Do you test if QueryUnload() fires?
>
>I didn't test that because I used an object created in the application, not the application itself (e.g. top-level form).
>
>I used a session object instantiated with Createobject(). I treated it as if it were my application object. As long as the application shuts down gracefully (no C5 errors), the memory variables are released and the Destroy methods all fire.
>
>If that didn't work, I was going to try and create a custom object bound to the _VFP object in the hopes that a CloseWindow event would fire and I could trap that. Unfortunately, _VFP doesn't export any events (at least not any VFPCOM ExportEvents can distinguish).

Thanks again. In thinking about it, QueryUnload() may not fire in this case. WM_CLOSE causes DestroyWindow() to execute. For some reason I also thought that a WM_QUERYENDSESSION might be issued and might cause QueryUnload() to fire.