A VERY quick test appears show that the SET MULTILOCKS OFF suggestion does stop the system from locking more than one record at a time, but does not solve a larger prob which is that using:
< MESSAGEBOX("This record is being used by someone else on the network",64,"RECORD IN USE")
< recinuse=.t.

appears to cause the active record to lock. This effectively makes a PESSIMISTIC ROW BUFFERING, which I do not want. I would like these guys to be able:
1) to SKIP past records in use;
2) view that are in use;
3) be notified that a record is in use so they don't waist their time making changes and causing conflicts.

Any ideas??



>Ok, now I think I see the problem. In those situations, I tend to use pessimistic row buffering and test for RLOCK() before allowing edit...it works for me. What is the setting of MULTILOCKS? Try setting it OFF if it is ON....but I really would lean towards pessimistic row buffering if I were you.
>
>
>>
>>The idea is to warn users that a record is in use but not lock them out of it (i.e. allow them to view it). So UT's Erik Moore suggested I try RLOCK as in:
>>< IF RLOCK()=.T.
>>< WAIT WINDOW "RECORD IN USE"
>>< ENDIF
>>I am using VFP6 SP2, have OPTIMISTIC ROW BUFFERING (O.R.B.) set in the DATA ENVIRONMENT, and have written no code to change that during the use of the form.
>>
>>So basically, O.R.B. is on all the time and when users make changes the record gets locked. I thought that when the after a TABLEUPDATE(.T.) and a SKIP+1 that the record that was modified would be unlocked, but that is apparently not the case. If a 2nd user views any of the records that the 1st user changed, my little IF RLOCK routine kicks in, which means that the record is still in locked. I want the record to be unlocked as soon as a user skips to the next record. Do I have to use UNLOCK or am I just missing something???
>>
>>
>>>Hi Ian ---
>>>
>>>First off, is table buffering still on for the table when you try the RLOCK(). Secondly, what is failing and what is the error message?
>>>
>>>Finally, RLOCK() and buffering doesn't always get along well....in VFP 3.0, for example, you had to issue a UNLOCK RECORD 0 after a TABLEREVERT() to unlock the header of a table.
>>>
>>>
>>>>After I issue a TABLEUPDATE(.T.), records that are no longer being viewed on tables with OPTIMISTIC ROW BUFFERING are failing at a:
>>>>
>>>>> IF RLOCK()=.t.
>>>>> MESSAGEBOX(XXXXXXX)
>>>>> ENDIF
>>>>
>>>>routine. Apparently they are not being unlocked. Why is that? Do I have to use UNLOCK???