>But once again I see no way I could ever put that in my current app
>
>If a single users has to re-type and re-try to save, I would have to pay someone to test my food and start my car

Hej, why you think users will have to re-type and re-try?
In my working (not a sample I posted here) algorithm data saving process looks like following:

1. User 1 change something and press save. During that user 2 saved changes so server now out of synch with local data.
2. User 1 saves changes. I use tableupdate(.F.,.F.), that means - "Do not overwrite changes on server if any". This is quick checking for changes on server if you're tableupdated not failed because other errors.
3. In such case I quickly check for differences between old values and values on server using oldval() and curval() functions. Depended on problem show message box to user - overwrite changes or leave them.
4. If user press Yes, I just use tableupdate(.T.,.F.) and thats all.
5. When user press Cancel - I cancel saving so user can go out and check if he really need to save these data.
6. When user press 'No', I than ask him if he want to review all changed field values compare to server changes. If user press 'No', I just save all changed fields that are not changed on server. If user press 'Yes', I loop through the changed fields and for case value of that field changed on server I ask if overwrite or leave for each particular field. You can test f value changed locally by GetFldState function.
7. After all above I repeat checking for changes for case when something changed again during time when user messed with above dialog boxes. If all ok,
use tableupdate (.T.,.F.) anyway, but with correct values from server. When not - repeat again.

SO, in any stage of saving user can cancel changes. N data needed to be retyped again. Above process also, when used with proper responsibility, never cause data loss or conflicts, when organized properly.