Robert,
the consequences are much worse than a simple failure. If the record is not locked then both users can write the record back. The problem is that whoever writes back last makes the final change. The 1st users changes are lost.

There are a number if theries about the best way to handle record locks and user edits in general. I have been doing this stuff for a long time and in my opinion the ONLY way to do it is to have Edit, Save and Cancel buttons on each screen. When the user wants to make changes they have to hit Edit. The click code in the edit attempts to lock the record using the code in my last posting. When they are done they click the Save button which does a TableUpdate() and then unlocks the record. Cancel just unlocks the record and does not update the table. If you have header and line records (parent and child tables) such as an invoice header table and a separate table holding the invoice lines then you only need to lock the header record to edit the header or lines. If the next user wants to edit lines he can't lock the header.

John.

>John, Thank you so much for helping me out.
>Do I understand you correctly in that you are saying this: when one application (user) wishes to issue a REPLACE statement BUT he is not sure if the record that is about to be modified is currently being edited by another user then he needs to aquire an implicit lock on that record using the rlock() function?
>
>What are the consequences? I assume the replace statement will fail and thus the data is 'lost'?
>
>Thank you.