The reason I was asking about switching to pessimistic buffering is that I ran into a problem (description in Q190496) where MSFT recommends to switch to pessimistic buffering to get over the problem. However, I found that even with pessimistic buffering the problem didn't go away.

Thank you for your help.
Dmitry

>>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?
>
>Well, the difference with pessimistic buffering is that the record will be blocked immediately, as soon as user A starts editing. User B will probably get something similar to "cursor is in use by another".
>
>Optimistic buffering only attempts the (implicit) record lock when changes are being saved (TableUpdate()).
>
>>
>>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?
>
>Yes.
>
>I would recommend optimistic buffering in most cases. The fact that two users can edit the same record is usually no problem: a) they usually won't, in practice, b) nothing bad happens if two users really do edit the same record: the last one to try saving will simply have to undo and start over again.
>
>Hilmar.