Hi Thomas
See below

>>I was talking about datasession object and base class introduced in VFP6 sp3.
>>To late in my opinion as most established VFP frameworks were written before that point, so could not take
>>advantage of these new concepts/possibilities.
>>But it is right time to be introduced in X# :-)
>
>Can only speak from expirience to VisualExpress and VisualExtend, both support private datasessions, VisualExtend especially has options to run some forms (for instance their special pick lists, date / datetime input) in the data session of the form calling the subform (which often makes total sense, as user auth/rights are built into SQL access and in many instances the data for the pick/lookupform can be read from the datasession of the calling form, speeding up data entry).
>Promatrix IIRC also supports private data sessions, but uncertain if only in professional version or in free as well. Pretty certain that Hank would not have spent that much time fiddling with xCase for that fwk if it missed that feature ;-)
>As Drew was alive for vfp >6, I think his fwk will have support as well, but here I am only guessing.

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
**can be grid search form
** store object ref to property oSearchForn
** store this object ref to a custom property on that form, so form can call methods 'underneath'


procedure EditCustomer  &&called from the search form itself via object ref
lparameter nCustId
  *find it in database
  *show edit  form
  *user make changes
  *press save or cancell
  *we return that choice   
  return lSaveChanges

procedure LookupCustomer
**show lookup search form
return nCustId 


procedure ShowCustomerInvoices
**show all invoices 
*select statement..
*report or such

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