Hi Marc,

Well you didn't mention TRANSACTION control before either.

I must admit great surprise that RLOCK() / UNLOCK even does *anything* under such circumstances! That would seem strongly like a BUG in VFP to me, unless VFP has some way (and if it does, it ought to be documented) to still keeep the records locked even while telling you that they are unlocked.

However, maybe PESSIMISTIC table buffering (4)would do the trick for you here - the records would be locked automatically from initial access until successful END TRANSACTION or ROLLBACK.

Good luck Marc,

Jim N

>Jim, John and Jose,
>
>Here's how my system works, explaining why I need locking under a buffering scheme. May be I'm doing it all wrong.
>
>Imagine a diamond inventory. Now imagine you have to write a sale program. And finally imagine that the weight of the parcels are subject to weighing differences (small but since prices are per weight are high, they have to be recorded).
>
>Now the sale is a "document", meaning that multiple parcels can be sold on one sale.
>
>Most of the time (read 95%) the weight sold corresponds to the weight of the parcel at the moment of sale as stored in the inventory, but it happens that there are differences, that ideally should be recorded by invoking an update program and change the weight.
>
>So here is what I do: I have a grid wherein the user can enter the parcel number, the parcel info necessary to enter the sale is then displayed in the other columns, and the operator enters the price. Pretty straightforward stuff.
>
>During this operation the inventory parcel record has to be locked, to prevent other people to change it. The problem I have, is I would like to be able to unlock 1, more often than not the last one entered, in case the modification program must be invoked.
>
>The sale information is stored in cursors that are posted against the database at save time under a begin/end/transaction rollback scenario. That is why I use buffering.
>
>The fact that unlocking the last record unlocks all and that otherwise no unlocking takes place is workable, but face it, I cannot call it 100% cosher.
>
>There are similar programs to records differences of state of the inventory (mix, sort, location etc.).
>
>Thanks for caring,
>
>Marc
>
>
>>Jim ---
>>
>>Thats my thought on this whole issue. I don't understand why there is locking at all with buffering in place.
>>
>>>I really wonder if RLOCK() and UNLOCK are actually designed to work with buffering of 5? And doesn't RLOCK() / UNLOCK conflict with the design objective of optimistic table buffering