Dmitry;

There are two types of applications where I have found pessimistic locking at the row level to be useful. One is currency transactions and the other inventory. Both types of systems have in excess of 100 users in my case and collisions did occur. I am not sure what your need is however, if you search the MSDN Library for topics such as:

Set Reprocess
Set Status
On Error

Check Chapter 17 of the VFP Programmers Manual.

Things to look out for:

1. The use of Append Blank
2. Access the table only at the end of the “Save” routine. Get in and out quickly to avoid the “out to lunch” syndrome. Some applications actually lock the file when the form is instantiated, which is not a good design in my opinion.
3. Let your business rules define what type of approach you will take to data entry. If overwriting the last users entry is acceptable then that is the rule. Otherwise you have more work to do.



Try creating two or more forms that take advantage of different types of locking using the same table. Run them on the same computer at the same time and observe the behavior. My findings did not agree with the literature created by others. When you get into complex transactions involving multiple tables, orders, inventory levels, commitments, back ordering and a number of other topics, you have to pay careful attention to your design.


Tom


>I have always used optimistic table buffering in my applications but I came across a situation where I might need to change it to pessimistic buffering.
>
>Under Pessimistic Buffering:
>What happens, on the network, when user A is making changes to a record and user B attempts to make changes to the same record. What kind of message does user B gets?
>
>Also, if you have pessimistic table buffering, user A can make changes to one record while user B can make changes to another record? Right?
>
>TIA,
>Dmitry