Hi Ian,

I have read through the entire thread and I guess that I feel that there is still something missing here.

Are you also using TRANSACTIONal processing?... if so that would explain the continuation of the lock *after* the TableUpdate - you must either EDN TRANSACTION or ROLLBACK to get locks released when TRANSACTIONs are involved.

Alternately, Might you be *thinking* that you are TableUpdating a certain table when, in fact you are actually TableUpdateing another one?... do you specify the alias/work-area in the TableUpdate. . . and are you sure that your lock check is on the same alias/work-area????

Finally, ISRLOCKED() *only* works for the current application where that function is executed - it will NOT tell you if some other user has the record locked!!! Yes, I know that the docs don't tell you that but it truly is the case and has always been so.

Cheers,

Jim N

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