Hi Charlie ---

This is sorta, kinda in the area that I'm going to use it. Thanks!


>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.