>>Ed et all,
>>
>>These statements are incorrect. With Row Buffering only the current record is buffered. With Table Buffering the entire table is buffered. On top of this there is another "buffer" (for lack of a better term) of changes for both buffering types. This is what makes functions like GETNEXTMODIFIED(), CURVAL(), OLDVAL, etc. work.
>>
>>Also, to be devils advocate, nobody's mentioned the use of views and p-views (my favorite approach) instead of buffering the actual tables.
>>
>>Cheers
>
>Colin,
>
>Unless you have spoken to the developers at MS then your assertion is flawed. We have no idea from the docs what VFP buffers. We know that row buffering allows one dirty record at a time and that table buffering allows multiple dirty records. We know that row buffering will do an implicit tableupdate if the record pointer moves off a dirty record and that table buffering does not. That is all we know.
>
>BTW, if row buffering does not buffer more thna one record, why does it require multilocks to be ON?

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.

Secondly, this is not my assertion. It is an assertion that I've heard more than once at various courses, conferences and presentations on VFP from 3 to 6 and an assertion that I've never heard refuted. That said, it still may be flawed (people used to believe the world was flat) but that doesn't mean it definitely IS flawed. If this is incorrect maybe one of the MS gurus that scan through here could correct this. Until then, you go with what you know at the time.