>Programming for shared access in a multi-user network questions -
>using pessimistic row buffering with MULTILOCKS ON.
>
>If I have two users editing records and issue the following TABLEUPDATE() command
>TABLEUPDATE(.T.,.T.,'mytable')
>the VFP Developer's Guide says that TABLEUPDATE() Releases all locks after updating the table. Does that mean that if User #1 is editing the frist record and User #2 is editing the second record, User #2 unlocks User #1's record lock on the first record?

No. Releasing record locks only affects locks held by the user that released the locks. One user can not affect locks held by others.

>
>If User #1 is editing and thus locks a record and User #1 presses the Prev or Next button which runs a command such as SKIP or SKIP -1, does that unlock the record lock for that single edited record? If User #2 presses the Prev or Next button and User #1 is editing the first record, does that affect the record lock on the record User #1 is editing?

Yes to the first question. If you are using row buffering, when you move the record pointer, VFP issues an implicit TABLEUPDATE() at that point for the record being left. No to your second question because of the reasons stated in the above answer.

>
>These questions are because I get an error that reads
>Record is in use by another user
>
>When I check RLOCK() it shows .T. when User #1 starts editing a record. It shows .F. when User #2 tries to edit the same record and I put out an error message that I created. But when User #2 moves to the next record and comes back to the User #1 record and tries to edit the same record as User #1 I get the message -Record is in use by another user- after User #2 presses Edit and actually goes to a field to start editing the field in record. I want my message to appear instead of the system message. But my message only appears when RLOCK() is .F. I don't know why RLOCK() is .F. the first time User #2 tries to Edit and .T. the second time User #2 tries to edit the same record as User #1?

I beleive you are getting the system message because you are using VFP's implicit record locking to handle your locks instead of a home grown system. When you try to edit a record with pessimistic buffering, VFP immediately attempts to lock the record. This is an implicit RLOCK() and not something you have to initiate. If it can't lock the record, VFP displays the system message. You could trap for this in your error routine so it displays your message all the time (you could check a few environment settings to make sure it was the appropriate to do this).

As for RLOCK() returning .T./.F. at different times, I can't explain that. RLOCK() also locks the record. Did the record pointer move for User #1 and lift the lock?