Erik,

>Documenting, maybe, but I doubt it

An intriguing clue from the VFPCOM docs:

When you run this sample, change the Connection String to point to a data source that you have available (i.e., Data Source=JVP).


>a COM object lives in a dll. All it is is a set of functions, and properties that are accessible by programs that know how to talk to a library through the COM interface- that is using the IDispatch interface to find the addresses of the named functions.
>
>But a dll can also host other functions that don't have to adhere to the COM spec, and VFP does provide hooks into its environment to allow external libraries to call VFP API functions. This is exactly what an fll does. All an fll is, is a dll that knows the names of available VFP API functions, and how to call them. I strongly suspect that VFPCOM.dll hosts both the VFPCOM.COMUtil object, and a set of functions that work like an fll does, calling VFP API functions.

So that would provide a way to identify the current datasession and select area?