>OK, that's fine. If I do the check on TableUpdate, after the 1585 error gets trapped, I'm now out of the form and into the On Error prg, with no way back to the form. The situation is the same. Control returns to the next line after the error, (which points to READ Events), and the next line is RETURN to the desk top, application quits.
>
>The ON ERROR is supposed to be a catch all (one per app) where you can gracefully trap an error, display a message, "Update Conflict, Nothing Saved", and continue processing. What have I missed.
>
>Recall in the example, the error is generated by VFP as a share violation not tableupdate() or tablerevert() problem. I also set the buffering to 5 on both tables and that generated an error 1705 (open exclusive) immediately when the second user opened the form.
>
>Thanks for looking.
>
>Dallas

I do not know if this will help, but in the ON ERROR routine, the command RETRY make VFP re-execute the line that raised the error. While the RETURN command (or exitting the ON ERROR routine with out a RETURN, etc) will cause the next line following the line that caused the error to be executed. If your ON ERROR routine determines the problem, and corrects it, then executing the retry may do the trick.