No, it's still not exactly :-). You may and should have all records viewable when you use RLOCK(). RLOCK() does not prevent users from moving pointer to the recors and view its values. The only thing which is prevented is editing/changing of these values. So, the old classical (I hope not to invoke much fuss here :-) interface means that in view mode all controls are read-only and you may click navigation buttons to view next/prev record etc. When you click Edit button you may apply RLOCK() (if you like this old-fashioned scheme, me not) and if it returns .T. you make controls writeable and start editing. You will UNLOCK the record on Save/Cancel point. This way you don't need in any buffering .

>Exactly. I must have all records at least viewable at all times, so RLOCK and PESS ROW BUFF are out. Therefore I beleive the only viable solution is to keep track of what is open using a 'master... who's got what open' table on the server.
>
>Thanx for the help.
>
>>It's natural and logical to use either one: buffering or RLOCK(), but not both together. If you applied RLOCK(), buffering does not make any sense, because you guaranteed 100% that the only user will change record data.
>>
>>>Hi guys,
>>>
>>>I understand that now, but the prob is that testing for a lock is not usefull because the record should (almost) never be locked when it is in a OPT ROW BUF table... or have I missed something?
>>>
>>>>Ian ---
>>>>
>>>>Basically anytime you use RLOCK() or FLOCK() and it returns true, you have to issue an UNLOCK ... so:

>>>>
>>>>IF RLOCK()
>>>>  MESSAGEBOX("record locked")
>>>>  UNLOCK
>>>>ENDIF

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

Edward Pikman
Independent Consultant