Thanx John. The prob with ISRLOCK is that it is only true with the record is locked and in a OPT ROW BUF table that is only for a split second.

I accidentally managed to get two threads going on the same topic. and here is the result of the other thread:


>FR: NANCY F.
>A. You want to lock the record for a user if they are the first one to call up the record. Yes? then issue IF RLOCK() then go on...but you need to UNLOCK when they leave the record...which isn't necessarily the same thing as a tablupdate, right? I mean, usually there's a way for user to save a record w/o exiting it.
>
>B. I'd probably prefer to use a semaphore table and not actually lock the record at all. I think this was suggested to you earlier so might not be what you want.
>
>>Thanx Nancy but 'no go'. I didn't think it through. Obviously ISRLOCK will only work when a record is locked and the only time a record is locked using OPT ROW BUF is the split second when it is being written.


>Ian ---
>
>Substitute the IF RLOCK() line with ISLOCK() --- I don't remember the exact spelling of the word and dont have VFP handy...anyway, RLOCK() test for and applies the lock \; you want the other function just to test for it.
>
>
>>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???