>>>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.

Does it default to on or something? I never set multilocks to anything and I've got buffering on almost all my tables. I set it in the DE or set the form's default, so maybe it's doing it for me?

-Michelle