>>>>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.

It depends a lot on the UC of database/table and the problems arising when and how often.
Vfp optimistic locking and sometimes elaborate validation rules work fine with biz applications
where data entry takes lots of time or might be interrupted by a 5min phone call of 60min duration.

Of course you are technically correct that the only secure way is to lock the back end records -
but you might develop a process to establish and hold those locks only for the few seconds of
actual data saves from cursors to backend.
First round checks for updates in backend compared to needed updates
if conflict, loop until resolved
loop to lock
update
release locks

works great for insurance agents and similar office jobs,
where the main problem was user opening complex biz case
and keeping RLocks open for indefinite amounts of time.

In the old days I always had to load data into memory
(in FPD into Arrays with a few extra fields)
do the editing and then start trying to safe,
doing a similar dance whenever multiuser access was possible.

Buffering just made it easier by a lot - normal programs
sometimes did not have that level of error prevention
if the error did not result in large money loss.

Well designed frameworks at least have hooks for different handling or
have pre-coded such safety nets, sometimes via logical locks through time fields.

Things like ticketing were never for optimistic locking IMO -
winner takes all.

my 0.002€
thomas