Hi John,
No too exciting or unique, but here goes.
The generic reports/exports/output form lists all reports the app can print, or alternatively, you can filter on a category. Each report is in a container of class Job. Each Job may have a DataQuery object that knows how to get the right records. It also may have an Interface object to get the user's preferences. I want each DataQuery object to have the option of being encapsulated in it's own DataSession. Since a DataQuery object is based on a container, I had hoped to drag and drop a DataQuery Object on the Job and get what I wanted. The DataQuery object could then create a Session, if required, and SET DATASESSION TO oSession.DataSessionID at the start of each data handling method. This did not prove to be reliable. I found several instances where the SessionID wouldn't change. During Destroy was a specific problem. Anyway, I now use a session object with a Create method.

This = An Export Job
IF This.DataSession = 2
   This.oSession = NEWOBJECT('SessionBase', 'Session.PRG', '', This)
   This.oSession.Create(m.SomeClassName, m.SomeClassLib)
   This.oData = This.oSession.oData
ELSE
   This.odata = This.DataQuery1
ENDIF
* Either Private or Default, I can refer to This.oData.

Now the SET DATASESSION stuff goes away. I can create two objects, use different preferences, then requery each. I can BROWSE the result cursor from object1, then BROWSE the same alias name from object2. Both can be viewed similtaneously. This allows for collating the report, since I can control their printing, a collategroup at a time.

BTW, the DataSessionID AND SET DATASESSION TO are interesting and fraught will peril. I plan on making some examples and writing a more thorough explanation of what to expect.
If you AddObject(Session) to a form, the session's ID is not settable...you can set it, but it reverts to the form's. If you createobject("Session") a new DS is created. If you run code within that object, it switches to the DataSessionID of that object--no matter what is was initially.
When a form is destroying itself, the DataSessionID may be unsetable. Things need to be handled in the Release.

When setting a DataSessionID, it may or may not reset the SET ("DATASESSION"). If the DataSessionID matches the SET ("DATASESSION") settings changing it to a different setting will change the SET ("DS"). If they aren't equal, setting the DataSessionID won't affect the SET ("DS")!

Sessions, Forms, etc. do have some hidden remembrance of what DataSession they were started with. If I create two forms with private DS's, and switch their DataSessionIDs, then Refresh() them, the data appears reversed. Everything works fine as thought the form that started with DSID of 2 had always been 3 and the form that started a 3 and now is 2 had always been that way. But on Destroy, the right session is killed off, as I recall.
Charlie

>Hi folks ----
>
>Anyone done anything neat and exciting and unique with the new Session baseclass? I'm looking at a situation where I might want to use it but it'd be nice to hear some "war" stories.