Hi Sergey,

This problem uncovered something that to me seems quite interesting.

The data is obviously there, available to vfp, as I can scan through the cursor, make calculations based on its data, etc., however, for some reason, the part of VFP's data engine that parses sql statements bounces against this as if there was a brickwall surrounding the cursor if you try to query it with sql statements.

The workaround I've found was to convert the cursor to xml and then convert the resulting xml to another cursor. It's easier and requires less explicit garbage collection than going the COPY TO route.

Thanks for your help!

Alex


>Hi Alex,
>
>It'll be possible to do with query in VFP9 with new "WITH (BUFFERING = lExpr)" clause. Until than you'll have to use non-sql commnads to access buffered data. For example, COPY TO command.
>
>>
>>I'm doing some conversion work from dbf's into a sql server database.
>>
>>One of the things I'm doing is populating a remote view with Table Buffering (buffering = 5).
>>
>>Before issuing the tableupdate() to commit the data from the remote view into the sql-server table, I need to populate an additional cursor with this uncommited data.
>>
>>For example:

use test_rv &&This is the remote view
>>append blank
>>replace name with "Alex", phone with "201-656-0132"
>>append blank
>>replace name with "Alex", phone with "201-656-1979"
>>append blank
>>replace name with "Susy", phone with "201-659-3300"
>>
>>select distinct name from test_rv into cursor people_cu
>>
>>* Do something else
>>
>>select test_rv
>>tableupdate(.t.)

Under the above scenario, cursor temp_cu comes up empty.
>>
>>I could work around it (and for the time being will do so), but am wondering if there is any way to get the data from a remote view into another cursor prior to committing the data to sql-server.
>>
>>