>>Sorry, no. The fact that VFPCOM uses an alias name, and not the table from disk means that VFPCOM is DIRECTLY accessing data from the calling process. Otherwise, how can it scan the table to grab the values? Remember, the cursor in question may not live on disk at all- it may only live in VFP's memory space.
<<

Right, via the LCK...



>>COM Servers never had nor will they ever have direct access to data from a calling process. I have never tried to make that argument. And, VFPCOM does not have a magical power that allows it either...
>>
>>Has this whole thing been de-mystified now???
>
>Sorry, no. The fact that VFPCOM uses an alias name, and not the table from disk means that VFPCOM is DIRECTLY accessing data from the calling process. Otherwise, how can it scan the table to grab the values? Remember, the cursor in question may not live on disk at all- it may only live in VFP's memory space.
>
>Open a table or view with row buffering on, and change a value in the current record. Employ VFPCOM to create an ADO recordset from that table, using the CursorToRS function.
>
>Now notice that the value that you changed in the table has been written to disk, and the buffer is clean. This means that VFPCOM moved the record pointer. What other COM object do you know of that can do this?