Hello Erik, buddy, old pal... I tried that RLOCK suggestion you gave me yesterday and it worked great! Unforunately (or fortunately depending upon your perspective) it brought out a bug. The following is the result of a post explaining the prob and if you would look at it, I would appreciate it.

_____________
Hello John,

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