Very nice! Thanks a lot ...

ray
>Raymond,
>A little sample implementation (code tells better) :

* Sample table is home()+"samples\data\customer"
>* In form Dataenvironment buffering is set to pessimistic
>* In fact we use rlock() so it could be any type - explicit lock
>* Form is done with form wizard
>* A timer (thisform.timer1) is added to form
>* Wizard buttons (thisform.buttonset1) code is changed as below
>* To test run same form in two different VFP tasks
>
>* txtbtns.init  (thisform.buttonset1)
>thisform.comment = thisform.caption
>DoDefault()
>
>* txtbtns.navrefresh  (thisform.buttonset1)
>DoDefault()
>thisform.Timer1.reset
>thisform.Timer1.timer()
>
>* txtbtns.cmdEdit.click (thisform.buttonset1)
>IF !this.parent.editmode
>  RLOCK("Customer")
>ELSE
>  UNLOCK in "Customer"
>ENDIF
>DoDefault()
>
>* Thisform.timer1.timer (interval ie:2000)
>SET reprocess to 1
>IF !ThisForm.BUTTONSET1.editmode
>  lCanLock = rlock()
>  UNLOCK
>ELSE
>  lCanLock = .t.
>ENDIF
>IF lCanLock
>  thisform.caption = thisform.comment + space(20)+"..Record available.."+time()
>ELSE
>  thisform.caption = thisform.comment + space(20)+"..Someone is editing.."+time()
>ENDIF

Cetin
>
>>"-Set buffering on (row, optimistic generally fits well. To check before starting edit pessimistic fits well).
>>-Set readonly = .f.
>>-Edit
>>-If "save" clicked try to tableupdate()
>>-If tableupdate() fails check why (Someone edited in between ?) and if you want force update."
>>
>>Setting the buffering as you described can be accomplished by using
>>=CURSORSETPROP("BUFFERING",2)
>>Is readonly = .f. just a example of the logic?
>>
>>thanks
>>
>>>Raymond,
>>>If all versions of Foxpro is concerned then rlock() is a life saver. When you rlock(), others could view it but not edit. Basic edit routine could be like :

* button activating edit
>>>set reprocess to 1 && Try a lock just once
>>>if rlock() && Is already locked ? someone editing ?
>>>* If you could access here then record is free for you
>>>* and you placed the lock now
>>>else
>>> wait window "Sorry someone is editing...Try later."
>>>endif
>>>
>>>* Save or revert button
>>>* Cleanup code
>>>unlock && Remove the lock so others can edit

This is explicit locking. With explicit locking you should control the unlocking too.
>>>Now with VFP buffering things are easier. Implicit locks do the most of the job.
>>>-Set buffering on (row, optimistic generally fits well. To check before starting edit pessimistic fits well).
>>>-Set readonly = .f.
>>>-Edit
>>>-If "save" clicked try to tableupdate()
>>>-If tableupdate() fails check why (Someone edited in between ?) and if you want force update.
>>>
>>>With pessimistic buffering, you could add a timer to your form that would just try to rlock() and immediately unlock to see if current record is free or not. You could disable edit if not rlocked, and enable when could be rlocked. You could test multiuser virtually on your own machine, invoking the form in different FP tasks.
>>>Cetin
>>>
>>>
>>>
>>>
>>>>Maybe I don't understand how RLOCK works, but I thought that it kept everyone off the record except the first person. That once someone was on a record no one could even look except AFTER the original person moved off the locked record. I have a situation where 1 person can edit and everyone else can only see read-only controls until the original person is done.
>>>>
>>>>>>If a record on a Network is brought up in a READONLY state ( all controls are READONLY), and there is a control to switch them to a READ/WRITE state is there a way to determine if someone else is using the record and prevent the switching to READ/WRITE?
>>>>>>Simply, everyone can look at any time, but only one can READ/WRITE on the record at a time.
>>>>>>
>>>>>>thanks
>>>>>Why Not RLOCK()
>>>>>Cetin