There aren't a lot of cases where you need to do this. Unless the probability of two users editing the same record is fairly high, or there's some other reason you need to keep a record locked while it's being edited, I would just use buffering. Then, check the result of TABLEUPDATE and deal with contention issues if it returns .F.

>I'm curious how people normally handle soft record locks with buffering? (In case I have my terms wrong, I mean where you put who has the record locked and since when into the record rather than using RLOCK()).
>
>Since the table is buffered, no one else in the system will see the change to the lock status fields unless I do a tableupdate. So when the user wants to edit/add, I change those fields, update the table, and then let them edit. When they cancel or save, I have to change them again and update the table again.
>
>I just get the feeling I'm doing things the hard way. Is this normally done in a better way?
>
>Thanks,
>
>Michelle