You did not specify which backend you used and if/how you checked for record alteration before save.

I never liked vfp leaning inside documentation on unchanged field values and generating single Update SQL statements for PK and oldvalue of fields to update ( WhereType: 3 or DB_KEYANDMODIFIED)in CursorAdapter via TableUpdate() for instance. WhereType 4 (DB_KEYANDTIMESTAMP ) does not need to be a timestamp in the datetime() sense - it can be used with any kind of field.

My solutions usually include a timestamp of last change (only half trustworthy on servers as server time might be altered by admin, even less on shared dbf, as field only reflects each clients idea of now()) plus a 4 or 8 byte counter for field writes to the record. Such fields are IMO much better to detect update conflicts or a need to update records in a cursor or a view, as you can compare field values. Timestamp trust for need of update less important, if you check on equality, not (later than record.timestampvalue).

Brutal but effective in avoiding subtle errors stemming from updated fields you selected, did NOT change yourself but used in record validation the change in value by others might kill validation. Crystal clear in showing that a record had been updated in between - if you were rigid in forcing those fields to update.

regards
thomas

>Hi all,
>
>I have never really had to use Refresh(). But now I have been asked for one small part of an app where the users have multiple records loaded in a view if "can we know if someone else has just made a change to a record" (I have used optimistic locking up to now).
>
>I looked a Refresh() and CurVal() and have tried to test myself. I have also read Hackers Guide to VFP and it answered some, but not all, my questions:
>
>I am thinking of including a datetime stamp on each record so that I don't have to check all the fields.
>
>Both screens where the editing take place have buffering set to 5 and there are multiple records in each. The users in one screen will typically save their data out after ever record edit. The users in the other "master" screen are seeing records from many users and they want to see the changes others make before potentially making their own changes.
>
>- the notes all say that Refresh() needs to be issued on the current cursor so that the data returned by CurVal() is up to date
>
>- it doesn't seem like Refresh() will refresh an entire view - it seems to be only 1 record at a time; this means I would be moving the record pointer through the master screen for reach record, issuing Refresh(1) and then changing the display to show that a change has been made (probably changing the colour of the row for changed records as a visual clue)
>
>- It seems Refresh() might be kinda kludgy to use - is that the right impression?
>
>Albert