>
>Marc,
>
>Pessimistic might be the way to go but it will be very restrictive for the other users of the system. You might want to investigate TABLEUPDATE() further. If you pass a .T. as second parameter it will force your change, that is, even if someone else has updated the record after you got an 'image' of it.
>
>José

Hi Jose,

I've been thinking along the same lines as you. For clarity, let me repeat that the records I wish to lock belong to tables that are not bound to the form.

But I guess that if I open these tables with pessimistic buffering, when I issue a (dummy) update (or replace) this would have the same effect as a lockg, and tableupdate or tablerevert would be the corresponding unlock in that case.

This scheme would allow me to generalise my framework to make it more client server friendly I guess. Could you confirm my hypothesis please?

TIA,

Marc