>>>Now it becomes weird. I have two bizobjects, which happily live in their own datasessions (as described and fixed in part I). There's a third object, assigned to a global variable, and it's supposed to live in DS 1. But it does not - as I've discovered now.
>>>
>>>This global object has a .buildlist(cField) method, which receives an expression as a parameter, and builds a comma-delimited list by scanning the current alias for non-empty values (uses evaluate()) of the expression and converts these values into SQL server compliant strings. The string it returns is something that can be used in, well, like this:
>>>
>>>

text to cSql noshow textmerge
>>>select * from thetable where thefield in (<<lcList>>)
>>>textend
>>>sqlexec(cSql, "crsAlias")

>>>
>>>I was using this code for more than a year, unaware that it executes in the DS of the caller, even though it has no parent (see part I) and should, therefore, execute in the default datasession. Other such global objects do execute their code in the default datasession.
>>
>>Dragan, nothing strange.
>>In VFP it doesn't exist "default datasession",
>>an object assumes the datasession of the scope
>>in which the object is created.
>>
>>then the the global variable object go into the datasession
>>of the method where you execute NEWOBJECT().
>
>But this object was created in DS 1, during the app start, before any new DS was created (no forms run yet, no session objects created). And it executes in any DS, which is the weird part, and then after a few calls it executes in a wrong DS, which is even weirder.
>
>And some other global objects, created at the same time, consistently execute in DS 1. Can't catch any logic here.

can you extract a repro. I don't look it