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

Data Source is the MS name for a named ODBC source...


>>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?

Sure, but more importantly, it would give the external dll the ability to SCAN the table, and retrieve the values. Opening a cursor and setting the buffermode to recordbuffering and calling the CursorToRS function gives some evidence to this point. Changing a value in the current record of the function and then calling CursorToRS causes the value to be written to the base table, which means the record pointer is being moved within the context of of VFP's workspace. The fll interface into VFP's API gives external routines a wealth of functionality and access into the VFP environment.