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