Hi Srdjan,

the syntax possible due to session usable as standalone clearly is better than linking forms and manipulating datasessionID at runtime - no argument.
But if I compare the twistings under FPD 2.x/FPW to get minimal isolation of table data from "undecided user input"
- most of the time using scatter to array for each record used as form-basis - as to not disturb others in multiuser apps,
with
the whole bundle of buffered input, isolated/encapsulated data sessions selectable via datasessionID, tableupdate, tablerevert, oldval, currentval, getnextmodified, get/setfieldstate and the necessary cursorget/setprop

the new way was so far ahead of the old paradigma... Re: you later comment about well written DOS prgs:
I had built most of my stuff based on an approach described in 2 similar books (DOS+FPW) based on having "buffered screens" via store to array, so that all edits were buffered until "save" was triggered, even for child and grandchild records.
Lots of checks and acopy if step was done in parent table to show edited but unsaved data...
The first forms I moved for at least 3 month ran under belt-and-suspenders approach: old functionality was kept as a sanity check to verify that the new stuff really did what docs described - not really "magic", but incredibly smart approach that at first I did not believe it was error proof. Removing the array based stuff felt GREAT. That is why I try to tell the xSharpies that this area is the true DNA of vfp, as it enabled the other goodies like remote views first, cursoradapter later, to give a locally cached subset of remote data to play with and then decide if saving made sense, needed further tweaking via full blown SQL if one wanted or should be thrown away. Most of the other stuff (data binding, mapping records to memory structures/arrays/objects) was doable (often less elegant/more wordy) in other languages, but the local buffered cursor or table for me is/was the secret sauce keeping me using it.

regards
thomas

>It is not about using private datasessions as such, that was possible by using forms with private data sessions or otherwise forcing it, but more of a easy modeling and clean cut architecture that session object and base class made possible.
>Some things were made incredibly simple and clean cut.
>Couple that with easy moving of local (wld be even better with remote!) cursors between these session objects and you get very very flexible and powerful playground..

>
>Here is small demonstration of what I am talking about;
>
>

>define class myCustDataEntity as session     
>*enforces private session upon object instantiation 
>*all other forms used use default datasession and act as limitation free form set basically
>
>cDataEntryForm='.\myDataForm.scx'   
>cSearchForn='.\myGridSearchForm.scx'
>cLookupForm'.\myLookupForm.scx'
>
>*Object reference properties to all the forms this data entity object is calling 
>*so this object have object handle to all forms it is calling 
>oSearchGridForm=.f.
>oEditForm=.f. 
>oLookupForm = .f.   
>oCustomerInvoicesForm=.f.
>
>*forms themselves keep object reference to underlying this data entity object as well. 
>&&init of every instantiated form gets ref to this object as parameter and store it for further use.
>
>
>procedure init
>set date british
>set multilocks on
>.
>.
>*etc.  
>
>this.OpenTables()
>
>procedure OpenTables
>use customers in 0 shared ...
>use invoices in 0 shared ...
>etc.
>
>procedure ShowCustomers
>procedure EditCustomer  &&called from the search form itself via object ref
>procedure LookupCustomer
>**show lookup search form
>return nCustId 
>
>
>procedure ShowCustomerInvoices
>**show all invoices 

>procedure SaveAllChanges
>
>**save buffered changes to underlying tables
>** (oversimplified meta code)
>
>begin tran
>err=tableupdate1
>err=tableupdate2
>
>
>if !err
> end tran
>else
> rollback
>endif
>
>
>procedure RevertAllChanges
>tablerevert1
>tablerevert2
>tablerevert3
>enddefine 
>

>This little 'entity framework' enables us to;
>- open tables in private session (shared) regardless of who has what open
>- Have multiple forms act as formset without any drawbacks of actual formsets. Forms can call underlying entity object
>and vice versa. Total control.
>- keep all entity related data tables together (customers, their invoices, payments etc.)
>You can build all customer related functionalities within the same data entity class and use it from anywhere
>in application;
>
>

>local oCustomer
>oCustomer=createobject('myCustDataEntity')
>oCustomer.ShowCustomers()  &&Search grid or other search form
> 
>*or
>oCustomer.ShowCustomerInvoices() && form or report
>*or whatever else customer related you made there
>
>

>
>once you release object.. puffff!!
>All gone and clean (depend how clean you want to be ;-) )
>all tables closed
>all forms/variables released
>
>Another beauty of this base class (session), is that it could have been very nicely utilized to reuse old legacy code.
>Suppose you have well written dos app part of which you want to port into VFP (or now X#) environment;
>
>Typically dos apps were stored in program files as multiple funcs and procs. Old fashion Structural programming
>with menu to (wait state) and many related funcs and procs acting as 'data entity' that are being called from that
>wait state or some other procedures
>
>So you take all the procs and funcs related to customer enclose them in class based on session
>
>
>**wait state
>** customer record shown, navigation buttons underneath
>menu to nChoice
>
>do case
> case nChoice=1
> do ..
> case nChoice=2
> do ..
> etc
>endcase
>
>**basic nav
>dosProc1 &&Top
>dosProc2 &&next
>dosProc3 &&prev
>dosproc4 &&last
>
>but more importantly we need;
>dosproc5 &&heavy calculations on customer data
>dosproc6 &&heavy calculations 2
>dosproc7 &&heavy calculations 3
>
>So using session object we could take procs we need and call them
>from our above described data entity object.
>
>

>define class myOldDosCustomers
>
>procedure Init 
>
>procedure OpenTables
>
>procedure ShowCustomers  &&form becomes new 'wait state' instead of menu to.. 
>
>** but then all the calculations we want to keep can be copied and become functional here as methods of the class
>dosproc5 &&heavy calculations on customer data 
>dosproc6 &&heavy calculations 2 
>dosproc7 &&heavy calculations 3 
>
>
>enddefine
><pre>
>
>And voila! Our old structural code becomes cool 'entity objects' :-))
>
><pre>
>local oCustomer
>oCustomer=createobejct('myOldDosCustomers')
>
>call that heavy processing procedure within new environment
>
>oCustomer.dosproc5 &&heavy calculations on customer data 
>
>

>
>and again you release object and poufff... all gone and clean.
>Beauty! :-)
>
>But still only in our bellowed VFP so far.
>That is why I mentioned session base class in this thread.
>Who knows maybe this seed will bear couple of fruits some day..
>
>Keeping my fingers crossed & hoping for the best :-)
>Sergio