>In the end, you get the same results...
I agree - as I said before, on a practical level it works - it is the same - I'm just miffed that it isn't handled automatically


> However, it may be that VFP only has the ability to automatically create the WHERE CLAUSE of the UDPATE STATEMENT for cursors created via a RV in a DBC.
that seems to be the case - I still call it a bug ...


>Heck, only tables that are part of a DBC can participate in VFP transactions... So, there is some precedent for this.
Yes - but an SPT Cursor CAN participate in a VFP transaction - so there is precedent for them to work "more like a view" here too - especially when we consider that a view is nothing more or less than a SPT Cursor "wrapper" - with pre-set properties - I still call it a bug ... I should get a T-shirt or something ...

>Regardless of whether you include the timestamp field as part of the key field list or as part of the where clause, in reality, it all means the same thing as far as SQL is concerned.
I agree, and will use your idea if I end-up using timestamps at all


Now - to ask something else related to SPT cursors while I have a guru's attention.
How and the heck do you deal with grids bound to an SPT Cursor when you have to "requery" the cursor - that is - reissue the SQLExec select (since SPT Cursors can not actually use the Requery() function) - Of course - I lose my binding - am I REALLY going to have to rebind the grids on the fly each time I repull data? What a PITA if that is the case! Viws are starting to look better and better ( if I could just get to that darn read only "sql" property!!!)

Thanks for your help,
Ken