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

------------------------------------------------
John Koziol, ex-MVP, ex-MS, ex-FoxTeam. Just call me "X"
"When the going gets weird, the weird turn pro" - Hunter Thompson (Gonzo) RIP 2/19/05