>>If you use RLOCK(), then you need in neither buffering nor tableupdate/revert. If record is locked by you, then nobody else will change it, right? So, what helpful information you may get from buffer?
>
>Ed and everyone,
>
>The argument here is confusing the multiuser strategy with the tools in VFP for implementing multiuser code. Securing a lock, in any way, before allowing an edit to begin is the pessmistic strategy for handling multiuser contention. Verifying the ability to save at the time of the save operation is the optimistic strategy. The selected buffering mode has nothing to do with the strategy other than the fact of the automatic things that occur.
>
>I, for one, hate automatic things occuring. If I want pessmistic strategy I use Optimisitc Table buffering and I deal with the locking. The buffering gives me the easy ability to edit fields directly and later decide to save or discard the edit. The optimisitc gives me no automatic locking except for during the save operation. The table buffering prevents any unexcepted updates from happening automatically because some code moved a record pointer.
>
>Using Opt Table buffering, I can implement either the optimistic or the pessimistic strategies for multiuser contention resolution. If I use pessimistic buffering I am locked into the pessimisitic strategy. Since buffer modes dictate how other code needs to be written, I prefer to globally use the same buffer mode for everything and write code to implement the appropriate strategy.

Well put Jim. I agree completely, in fact this is the approach I take. I always use Opt. Table buffering and handle locking strategies and the decision between single record or multi-record updates in each situation.