>>First of all to the MULTILOCKS question - if this is true I have the same question, however as far as I know, MULTILOCKS has nothing directly to do with buffering at all. If there is a need to lock more than one record at a time then MULTILOCKS must be on. With Table Buffering this need exists, with Row Buffering it doesn't.
>>
>
>My assumption is that buffering is done in an invisible CURSOR. When you edit the field, an implicit lock is placed on the record in the buffer. (CURSOR)
>
>When you tableupdate() a lock is place on the record in the actual table (TWO LOCKS NOW EXIST) so that it can be updated.
>
>BOb

Yes, two locks exist, in two different tables (sort of?) ... multilocks is only supposed to be about locking multiple records in the same table.

By the way, it "is true". And I have the same question--why? But in order to set a table's buffering to any mode other than 0 (zero), SET MULTILOCKS must be ON. I don't remember if CursorSetProp("buffering", x) gives an error message, or just quietly fails to set the property, but you can't turn on any buffering with SET MULTILOCKS OFF. (As the help and docs on buffering say.)

My US$.02 worth.