>>In my apps I sometimes notice that data sessions with open tables are left around after a form (and sometimes the app in dev mode) is exited. I assume that this is a bad practice.
>>
>>Any suggestions on a routine to call in a forms.destroy (or other method) which would handle the data session and any lingering object references?
>
>Let's take just one example. I'd look into why they're being created, first. Are you using SESSION object? Or do you use SET DATASESSION TO in production code? Private DataSession forms, reports? Default? Mixture? If you can zero in on one example, that you can reliably duplicate, then we could offer some suggestions. Otherwise, we'll just be guessing. Not that that's ever stoppes us in the past, but it would help focus the replies.

Another thing I'd check is if there's some uncommitted changes in the buffers. Usually a violated primary key which caused a tableupdate() to return .f. or something like that. Depending on error handling (which sometimes acts as error hiding - I had such a case) such a thing may pass unnoticed until you try to close the tables. A way to decet this is to try to close the dangling tables from the command window or data session window, with error checking set to default. If any of the tables gives out a message when attempting to close, that's it. If not, it's something else.