That's fine with me, Ian, do whatever you like.

BUT... this is a 'problem' each and every one of us has faced and it is basically second-nature to most of us and is known to work perfectly well and accurately (telling some user they cannot have a record now because someone else currently has it). In your case, with OxB, it differs only really in that the period where this can happen is much shorter than it might otherwise be. Of course it can also happen that someone else has updated the record you also need to update, which is another problem altogether.

In summary, it still feels strongly that there is something missing here.

Cheers,

im N

>Hi Jim,
>I am not using TRANSACTION but unfortunately two threads have been running on the issue and I think that after 3 hours and about a million suggestions, the only way to check if a record is being viewed is to create a table track who has what open.
>
>Thanx for your effort.
>
>
>>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???