>>>>It also seems that the following it true if use DataSession=2 (Private):
>>>>
>>>>1. The COM object is always created with a fresh, empty, data session. For every instance of the object, you must explicitly USE all tables that you want to have open during the life of the object.
>>>>
>>>>2. When the COM object is destroyed, all open tables in its private data session are automatically closed.
>>>>
>>>>This is what I'm seeing with the tests I'm doing. Behavior here is distinctly different than when you use the default data session, in which case both tables and cursors remain open across instances of the object.
>>>
>>>- the session object build the datasession
>>>- every object attached to the datasession ( via SET DATASESSION TO into an object's method)
>>>increase the datasession's semaphore
>>>- only when the semaphore become 0 the datasession it is released ( except some bugs )
>>
>>What I need to be sure about is the isolation/encapsulation of data entities such as cursors within an MTDLL. I need a session object to work like a form object works when created with a private data session in an interactive VFP EXE. Two concurrently running forms in the same EXE with private data sessions can both create cursors of the same name and each cursor is independent of the other. To me, this example is similar to the apartment model threading in an MTDLL because both forms would be using the same "Thread-local storage" (in this case it's a single threaded application, but the model holds up I think). This is what I need to have happen in my MTDLL... i.e., where two objects of the the same OLEpublic class can concurrently live on the same thread and not walk on each-other's dyncamically-created cursors.
>>
>>Furthermore, if a method of a Session object (created with a private data session) calls a procedure in an external FXP file, and that procedure then creates a cursor, I also need that cursor to share the same data session as the object itself.... so that there's no automatic switching between a private and the default data session in such a circumstance.
>
>VFP works this way. FXP's procedures they work in the datasession of the calls.

Thank you!

Let me ask... is there a practical reason to switch between a private data session and the default data session? Or to switch between just private data sessions? I've often wondered this because it seems there is no straightforward way to move data between them. I've thought it would be helpful if there could be private data sessions plus a "global" data session that every private session could also see (would require a slightly different architecture than VFP is), but would have some practical uses.