>>Otherwise, I use properties of my oApp object to keep up with what DS I want to be working in for some of my app class methods. If oApp.nDataSession is zero, methods that look for this use the currently selected DS. Otherwise, the method code switches to the DS value found in that property [and switches back to what it was when finished, of course].
>
>Beautiful Mark thank you! That saves me a whole bunch of non-billable research!
>
>Now a new question, has anybody else noticed that the development environment gets really Dr Watson prone when passing around DS ID to manipulate the current DS ever since SP3? I've crashed burned ever time I mess with passing a DS ID ever since SP3, never could put my finger on a specific bug but I've bitched and moaned a whole lot regarding this.
You are probably looking for a different perspective, but I still use the oApp properties to do this. The oApp object was created at launch time in the VFP Default DS. By letting oApp handle the changes or store the DS in a property you want to be/remain current, I do not have such problems during development or run time.
I have a small PRG that I only run at development that sets up my oApp object, etc., to help simulate the run time environment.
Mark McCasland
Midlothian, TX USA