Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Unlock trap
Message
From
30/10/1998 06:34:30
 
 
To
30/10/1998 04:55:22
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Title:
Miscellaneous
Thread ID:
00152187
Message ID:
00152670
Views:
25
Mark,

I believe that you are incorrect that pessimistic table buffering locks the table header. The documentation states (at least for VFP6) that it locks *RECORDS* until TableUpdate. Since TRANSACTION processing is not mentioned in any of that write-up, my *guess* is that records in such a case stay locked until END TRANSACTION / ROLLBACK.

And by the way, I would dispute your statement: " The whole point of buffering is so you don't have to manually use rlock() VFP does it for you. ". I would say that it's whole point is to minimize *interference* with users employing an application, by permitting multiple of them to access the same record(s) at the same time. But, personally, I don't like that approach at all because it forces me to write code to make decisions that I really am not capable of making when there is an update conflict. Add to this that the situation shouldn't really arise that often and it means that I am forced to code fairly complex routines for highly intermittent usage. I would rather code in such a way that I do my best to free up locked records ASAP, relying on users to not keep them locked overly long (which is generally workable because frustration usually has the locked-out user to stand up and scream 'who's holding xxxxx for so long!'.

Cheers,

Jim N

>>Hi Barbara,
>>
>>The RECORD clause does not make any difference. I put buffering on 3 i.o. 5 and again no difference. It seems you can only unlock all or none, and unlocking the last in effect unlocks all, and unlocking a record that is not the last locked, doesn't do anything.
>>
>>Thanks for caring,
>>
>>Marc
>>
>>
>>
>>
>>
>>>Marc,
>>>What happens if you use the record number clause? UNLOCK RECORD 1 or UNLOCK RECORD 1054 (you should be able to find the record # you want easily).
>>>
>>>HTH
>>>Barbara
>>>
>>>>Hi,
>>>>
>>>>Here is my situation:
>>>>
>>>>vfp 5, support pack 3 installed.
>>>>set multilock on
>>>>buffering is set to 5
>>>>
>>>>In a private datasession, I lock 2 different records using rlock().
>>>>
>>>>I use UNLOCK to unlock (what I hoped to be) 1 record. The problem is that if I unlock the last record, all the records are unlocked, if I unlock the first record, no record is unlock.
>>>>
>>>>Can anybody shed any light on this?
>>>>
>>>>TIA
>>>>
>Marc,
> You can't rlock() buffered data. By setting the buffering to 5 (or 3) your getting optimistic buffering, which means the record/s are not getting locked in the table while they are edited, VFP will lock them when you call tableupdate() though, which means anybody can edit the records while you are editing them.
>If you set buffering to 2 - pessimistic record buffering or 4 - pessimistic table buffering the records will be buffered and they will be locked in the table for you so nobody else can modify them while you are editing. If you set buffering to 4 the header of the table will be locked which means nobody else can edit any records in the table while its locked. The whole point of buffering is so you don't have to manually use rlock() VFP does it for you. Hope this helps.
>
>Mark
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform