>>UPDATE CONFLICT errors occur when user A edits a record, and another user B has changed the data in that same record before user A issues the TABLEUPDATE.
>>
>>You may want to create a generic method ("m_Close") that is called by the Destroy method, Query unload method (I've never tested if the QueryUnload call Destroy, but I will now) and any other "exit" type buttons and this "close" method would handle reverting of updating data as needed. It would be within this method that you could trap for table update errors.
>>
>>With table update errors you could use: TABLEUPDATE (.T.,.T.) where the last update wins or use REFRESH to refresh the data from the underlying table and allow the user to re-edit the fields that have changed, or make the user tablerevert and then make them access the record again.
>>===============
>>>>I'm working on a VFP 5.0 multi-user application. It's using optimistic table buffering. On occasion a user will get an UPDATE CONFLICT error message when closing a screen. I've been able to duplicate the error, but I'm not sure how to solve the problem. It doesn't generate the error on the TABLEUPDATE() command. It happens when you try to close a screen. It seems to have a problem closing a table in the data environment.
>>>>
>>>>
>>>>Any suggestions at what I should be looking at?
>>>>
>>>>Maria Arendt
>>>
>>>You could try to issue TABLEUPDATE() or TABLEREVERT() (depending on form's functionality) in Form.Destroy event.
>
>
>In TABLEUPDATE(.T.,.T.) what is the second parameter for?
>I am currently using TABLEUPDATE(.T.).
>
>Maria
The second parameter(.T.), tells the TABLEUPDATE function to automatically overwrite all the data in the live table. This means that any changes made to the record by another user since you originally grabbed it will be overwritten with your changes. This will effectively do away with you UPDATE CONFLICT. This is the "LAST USER WINS!" scenario.