>Okay, all, I'm on the verge of losing my status as local VFP guru (and the little respect which I derive from it <g>). One of my guys asked how he could locate some data in a remote view without moving the record pointer. I told him he could run a VFP SQL SELECT against it, because SQL does not move the record pointer in the target cursor.
>
>Well, he came back saying that I was right insofar as I went, but I hadn't mentioned that buffered changes would not be retrieved. And he's right -- apparently, SQL against buffered data returns OLDVAL() values, not changed values. In this case, that doesn't work because he is doing data validation -- which makes OLDVAL() particularly useless :)
>
>I told him to go back to the old way (saving the RECNO() or primary key, using LOCATE, and then returning to the original record) but this is bugging me. Is there any way to get a VFP SQL SELECT to look at the data in the view? This implementation makes no sense to me, because everything else (LOCATE, SCAN, BROWSE, etc) looks at the changed data. Or am I doing something wrong?
>zahid

Zahid,
SQL Selects open the tables again (USE sometable AGAIN in someotherworkarea). It does this by design so it can change the active indexes (for one thing) and not have to reset anything. Because it opens the table again, it uses the disk presence of the table and this does not have the changes yet. The other commands use the alias specified so it looks at the buffered data.

So the answer to your question is you can't do this using SQL Select. You have to use the old xBase commands.