Maybe needs one or both of these ?

SET DATABASE TO blahblah
SET DATASESSION TO blahblah


>Hi Hank,
>Realise this is an old thread but ran into a new wrinkle on this. User has a form open and then they have open on a screen an "open" dialog (which in this case is an OLE open dialog by Microsoft). While they have it open, the system timer of this app fires, which fires every 5 minutes, and it does a look up of some values as to whether the app should shut down (a system-wide shutdown triggered by an admin). This app timer calls a *function* in a .prg file that is a procedure file loaded at started.
>
>At this point, code in that function starts to fail. And it does not fail because the code is not bulletproof i.e. the code opens the system table if not already open to look for this "shutdown" entry.
>
>So a form class is running one of its methods and that method is currently sitting waiting for the user to close an OLE control (which is subclassed in a class by me to make easier to use) and then a system timer fires (a class) that is running its "on timer" method which then calls a function in my procedure file. It fails when opening a table (the table name is passed in as there are two of them); fails on the USE code:
>
>

>   IF USED(lcAppTableName)
>      SELECT ( lcAppTableName )
>   ELSE
>      STORE MakeTempCursorName("Info") TO lcTempAlias
>      USE ( lcAppTableName ) ALIAS ( lcTempAlias ) AGAIN IN 0
>      SELECT ( lcTempAlias )
>      STORE .T. TO llTempOpened
>   ENDIF
>

>
>When tracing, it seems it is over a "system" datasession (i.e. the framework opens some tables upon startup in their own datasession). The timer lives in a globally declared var so not sure what datasession that lives in.
>
>Albert
>
>>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.