Kevin0-

>I am only talking about private data sessions here and I don't use the Set DataSession to command in production code. It looks like to me that parent tables from some of the local views used in the data session are left open.

Some? But not all? What's different about the ones left open? When you say it looks like it to you, I'm sorry, but I have to ask...are you _sure_ they're left open? For example, do you break the program after the form is closed (or even in the destroy() and then step through) to check the datasession state?

> Also I seem to have a cursor or two from some on the fly query (which I know I shold have taken care of).

Those should be closed too.

>
>I was thinking of just determining what data session the form is using then in the destroy method of the class, check if a private data session and then close all the tables in that data session -- make sense?

It shouldn't be necessary, ordinarily. When you do a SQL-SELECT in a form with a private datasession, the underlying tables are opened in the private datasession. When the form is closed, that data session is closed, for you.

As for the datasession, you're looking for the DataSessionID property. But, I'd look into why the tables aren't closed rather than forcing them closed in the destroy. I think you'll just be masking the problem or suffer unexpected side effects.

If you want to try and track down the real problem, the first thing is to confirm the tables are being left open. In a simple example. What tables are open? When do they get opened, exactly, and where. How is the form called?

I made a simple modeless form with a private DS. I opened a number of tables different way...in the dataenvironmnet, thru a USE and thru a SQL Select and then set auto close tables off (and tried it on) and found the DS was released and tables closed each time.

I wonder...any chance the form itself isn't being released? If you have an orphaned object reference? That would keep your app from closing though, so I suspect that's not the case.