Hi Albert,

when you access a class from a class, there's no issue. When you are in a class, then call a prg, and that accesses a different class, you can run into issues. Save the DSID and reset it in the prg. Because this is done so often, we created a prg set_dsid() that returns the DSID when called with no parameter, and when passed a parameter sets the DSID if that is not the current one.

Hank

>I don't think there is a timer running but good thought. It seems to be that there is a process running that when the form gets deactivated (through bring forward a dialog box), that a global form object changes the datasession because there is deactivate code that runs that then calls this global object which has the default data session (I think it does this to check if the user is trying to exit the app - did not trace through all that - suffice to say that I cannot make the assumption about which DS I am in when my other code runs.
>
>BTW, someone mentioned here about the fact that when a custom global object is instantiated that it lives in the default datasession (or something like that) - I had never really thought of non-form objects being "attached" to a datasession...
>
>Thanks,
>Albert
>
>>
>>If the framework has a timer active somewhere, every run of .timer() would switch the DS to the DS in which it was created, then back to previous one when it returns. Ditto for skipfor expressions in menus, if they contain code calls.