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

>
>And now it gets weirder... I was calling this code from both bizobjects. First time around, it executed in DS 2 when called from the first one, then in DS 3 when called from the second one. So far so good. Second time, when called from the first one, it executed in DS 3 (!). I got a file selector, because there was no alias selected in DS 3, or I got an error because the expression was invalid in terms of fields of the currently selected one.
>
>I didn't get any further in debugging these - I had to move on, so I copied the method to the bizobject's base class and it now works for me.
>
>Haven't tried in VFP9 - it may take us months to switch, and this glitch isn't such a showstopper anyway, and I don't have the time to recompile and try everything in VFP9. Maybe after I finish this big chunk of the project. So, assume this stays in 8sp1 for the time being.
>
>If it's of any importance, all the classes involved are prg-based.