You know Claude, I'm not sure how accurate that information is. For example, consider this excerpt:

[[However, consider code like this

SEEK Customer
INSERT INTO customer (balance) values (balance + amount)
This code is NOT threadsafe because another thread could do a SEEK to a different customer. To make this threadsafe, you can wrap it with a critical section, but a better solution would be to use a private datasession. Using a FORM or SESSION baseclass with Datasession=2 ensures this. Private datasessions in this scenario are logically the same as 2 different instances of the same form in the same instance of VFP.]]

(me again) In this case, according to other info I've read, it would not matter in an MTDLL if another thread did a SEEK because it would have it's own thread-local storage (it's own apartment) and thus effectively its own datasession. However, on MSDN is does say:

[[Visual FoxPro uses thread local storage to store a unique set of application and environment global data for each thread (apartment). This means that two instances of the same class created on different threads cannot access each other's data. However, if these same two instances reside on the same thread, each object can access the other's data. This could cause timing issues for your applications. In fact, as long as two objects on the same thread are created from OLEPUBLIC classes in the same .dll server, data from those objects is common between them (Note: You can use the Session class to give each object a unique private datasession.)

In addition to thread local storage, Visual FoxPro also provides each project (.dll) a unique set of globals data. Objects created from different projects (.dll servers) cannot access each other's globals, even if the two objects reside on the same thread.]]

(me again) Now what I don't understand is: Under what circumstances can "these same two instances reside on the same thread" as mentioned above????


>There's quite a bit of discussion on datasessions within a VFP mtdll at:
>http://www.activevfp.com/dev/dna08.htm
>Also make sure you're at VFp 6 SP5 or above since major mtdll issues were fixed with that SP...
>>Can somebody please explain this behavior to me:
>>- I have defined an OLEPUBLIC VFP class derived from CUSTOM, which I've compiled into an MTDLL
>>- I create a COM object from that class within ASP
>>- Within a method of the object, a DBF is opened (this would be in the default datasession since the class is derived from CUSTOM rather than SESSION, no?)
>>- The object is destroyed when the ASP page finishes
>>
>>This all works fine. But what I don't understand is this: When another object is created from the same class (let's say I load the ASP page again), I would expect the table to still be USED, but it's not. All tables that were opened during the life of the object are apparently closed when the object is destroyed.
>>
>>This is _not_ what I expected. I thought that the default datasession was scoped to the the DLL, rather than only being scoped to the life of the object. I thought that once a table was USED, it stayed open until it was explicitly closed by code or by unloading the MTDLL (restarting IIS, in this case).
>>
>>Could somebody please explain what's really going on? I need more understanding of which data structures are "global" and persistent within an MTDLL vs which data structures are scoped to an object created from a (class within a) MTDLL as the object goes through its life cycle.
>>
>>Thank you!!