How to use buffering with security of file locking

[suec032a]

I am currently using (buffering,5) for a pageframe consisting of 3 pages: - page 1 and 2 show a single record, but page 3 is the many table.

The application was originally written in 2.6 using rlock() and the user was informed immediately they tried to display a customer that someone else was displaying. This type of behaviour is still required as a request to change a customer's record is normally performed whilst the user is on the phone to this customer. This can be up to 5-10 minutes. It is a very small office of 3 people.

I have read a lot of the past posts concerning this topic and I realise the value in buffering, but I am wondering is there any way that I can let a user know that someone else is viewing the same record and stop them from displaying it?

Thanks so much

sue

 

[Olaf Doschke]

locking is never read locking, it's only write locking. And it's seperate from buffering, but indeed it's involved in the Buffermodes VFP offers: optimistic and pessimistic locking and row- or tablebuffering (both simple binary flags) are put together in the buffermode of a table or alias:

Cursorsetprop("Buffering",4,"alias") is for you: This is pessimistic buffering and will disallow changes to a record, that has changes from somebody else. Locking is automatic, but what's not automatic is locking of related records, a whole group of records and such. You'll need to manually RLOCK() records you want locked additional to that buffermode, if you want that and this way of achieving locks is still a valid approach to get exclusive access on the record level, before changing the record, as Buffermode 4 only locks when you really edit a record. In case of phoning with the customer, the one who phones with him should be able lock customer data preceding the phone call (if he does phone the customer) or at least at the beginning of the phone call (if the customer calls in).

What I typically did in such a case was only locking the main head record, eg the customer record, and program the business logic to account for that, eg disallowing changes to detail records of customers, if the biz logic can't achieve an RLOCK() to this head record.

It's easier to maintain and to be technically able to still edit detail records as they are not locked can be seen as advantage (eg administrative) or not. That's your decision.

Bye, Olaf.

 

[suec032a]

Thanks Olaf.

I am still fairly new to VFP so please excuse my basic question.

So if I used the rlock() to lock the customer record, is there any conflict with still using buffering,4 on this table?

Thanks

Sue

 

[Olaf Doschke]

No conflict, you can do both, it's a good idea to do so.

Once you have a lock, rlock returns .t. and also automatic locking does not fail, therefore manually locking does not interfere with automaic locking, you just gain more control about when a record is locked.

Bye, Olaf.

 

[suec032a]

Thanks so much Olaf

Sue