>>>You've just got to the point where it got complicated, see above. You now have just a way to detect that the serverside record has changed meanwhile, nothing else. The server will not tell you which fields are different. I'd like to have a db server which would, but AFAIK they don't.
>>
>>for that the server would need to save each record retrieved... but you could implement a history of changes
>>via timestamp / record change counter from other post ;-))
>>
>>>To know what changed, you'd need to retrieve the current version of the record (into a separate cursor), then compare field by field with your current record etc etc, as described in that long paragraph with ouches and parentheses above. Life is tough.
>>
>>Nawww, general routine to compare all the fields plus option to show all or only changed fields
>>with 4 columns for fieldname, transform(newval), transform(oldval()), transform(serverval())
>
>Yup, same thinking here. Yes, lots of work, but then do it once generally, not for each posible table separately, but as a general routine. Sounds like a candidate for framework code.

With native tables the *only* way to get a current, valid copy of what's in a row or table is to obtain a lock. The field by field comparison will work if locks are obtained, otherwise it would be indeterminate, as another user could update after the compare cursor is created and/or while the user is thinking about whether to commit her changes, cancel, merge somehow, or ?

With a remote back end I understand something similar can be achieved by diving into the wild, wild West of database hints. SQL Server offers (amongst others) UPDLOCK, which prima facie addresses this sort of situation. Never having used them, I don't know:
- if they're natively supported in CAs or RVs, or is SPT required?
- if they're automagically invoked when calling RLOCK( )/FLOCK( ) on a CA or RV. I suspect not as that would depend on the specific back-end and maybe the connection method (ODBC, OLEDB, other)

One discussion of UPDLOCK is at https://www.mssqltips.com/sqlservertip/6290/sql-server-update-lock-and-updlock-table-hints/

it's always been a mystery to me how VFP optimistic/pessimistic buffering strategies are supposed to work against a back-end which doesn't know anything about the internal locking gyrations of VFP client code, only its own supported hints.