>Jim, what do you think about other question derived from this thread: what's the necessity to have SET MULTILOCK ON in the case of row buffering, i.e. only one record seemingly would be locked? Is it just a precaution against some erratic user already locked (with RLOCK()) one record on the table and now started to edit another record with row buffering?

Ed,

I think it has to do with how VFP handles the oldval() curval() and buffer value along with the getnextmodified. MY suspicion is that there is very little difference between row and table buffering inside other than how many records are allowed to be dirty at the same time.

The use of locks and the multilocks setting required falls apart when thinking of optimistic buffering because the record is not locked until the update occurs, VFP could easily lock one record at a time for that even with table buffering and multiple dirty records.

I think the multilocks requirement has something to do with the affect that it has on the data buffers. They must be in that mode for the "buffering" to work.