>>>>>>When using default data-session,
>>>>>>all under-laying tables of an updatetable view (seleced in DE)
>>>>>>are not released atutomatically with the view when form is closed.
>>>>>>
>>>>>>Is this one of the DE bugs?
>>>>>>(Note that the tables are not opened before opening the view.)
>>>>>>
>>>>>>How do i overcome it?
>>>>>>
>>>>>>Thks.
>>>>>>
>>>>>>Han Wah
>>>>>Han Wah,
>>>>>
>>>>>This is by design. The tables for any sql select statement are left open and always have been. If you want them closed you must close them yourself.
>>>>
>>>>Any tips on how to close all the tables open by the view on form release?
>>>
>>>Unless your app design prohibits it, the easiest way (IMHO) is to use private datasessions. A cursor cannot stay open if the datasession it resided in no longer exists (which is what happens when a form witha private datasession is destroyed).
>>
>>The strange thing about this is some forms with views seem to be able to close all the base tables properly while others can't. It is one of those badly documented VFP features again.
>>
>>I read in a book that MS doesn't recommend us using private data session and I also read about problems in private data session in UT. Do you find using private data session easy? Besides having the trouble to 'SET' the environment for each session, are there any more disadvantages?
>
>I haven't read of the problems you speak of. I would like to hear about them (from you or anyone else).
>
>I find using Private DS very easy. It takes a little extra code to synchronize record pointers between forms (when going from one form to another that use the same tables), but this is usually offset by the code that you can get rid of that used to save record pointers so a form can be sure it is on the right record. With private datasessions you know for sure that nobody else has messed with your record pointer but that form.
>
>As far as setting the environment for every form, there are only a couple of proerties that I find it necessary to consistently reset in my forms; REPROCESS and DELETED. These can be set easily in a method in your form class. Call the method in the init of the form, or the init of the DE. IF you already have a DE class (this is an abstract class that cannot be created visually), then this issue becomes even simpler.
>
>I have used private datasessions from the very beginning, and have never had problems that I attributed to their use. IMHO, they force the app to more closely abide by OO rules. Everybody looks out for and cleans up after themselves. Very clean package.
>
>I know that there are lots of people out there that prefer using the Default session, (If I'm not mistaken, Edward Pikman is one of them) and I am all ears as to their reasoning.

Yes, you are right. But the reasoning here is just expansion of unbound/bound control plus buffering paradigm. If you are committed to bound controls with buffering, then you are committed to private data session too. If not, default session allows all the same functionality as multiple private session using form-driven approach, i.e. the centerpiece of this interface is Form.PrimaryKey property evaluated in Form.Activate event.
I completely agree that all this stuff is question of personal preference, first of all.