>>
>>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

Marc,
I am of the same opinion. But I cannot confirm it since I have experience with only Optimistic row and table buffering. You speak about "client server friendly". If memory serves, remote views support optimistic buffering only.

José