Tom,
Thank you very much for a detailed and very helpful message.
In my case, I am working on an inventory system with about 20 users.
And I thought that I was following the rules you outlined in your message, such as, updating after Save button, etc. I ran into a problem where during the update routine the application didn't see the data properly. The reason was a bug in VFP 6 (I don't know if they fixed it in 7.0 though). And the solution recommended by MSFT document was to switch to pessimistic buffering. Otherwise, if not for the bug, I think I would be able to design my program to work with optimistic buffering, no matter how many users hit the data.

Again, thank you for your help.
Dmitry

>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