Jim, I would have similar suspicion that there is exactly the difference what and how many records VFP will check in cases of row and table buffering.

>Colin,
>
>I *suspect* that you are reading the documentation too literally.
>
>I truly *doubt* (but must state that I wouldn't know for sure, and don't know how anyone else would) that *ONLY* the record is ACTUALLY buffered for ROW buffering. Rather I *suspect* that VFP simply ensures that only the buffered record pertinent to the 'active' record is considered in any processing done when in row buffered mode. It seems a safe bet to me that VFP has lots more records in the buffer even with row buffering active.
>
>There is also the question of the 'buffers' which we never 'see' and never have access to, but which are critical in delivering the performance VFP is famous for.
>
>Cheers,
>
>Jim N
>
>>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
>>
>>>Hmm... Then I just wonder why there are still people around using row buffering. Maybe someone who does it will jump in and clear the issue?
>>>
>>>>What Sylvain said. :)
>>>>
>>>>>I think that VFP will buffer only the records that were modified since the last TableUpdate()/TableRevert(). Not the complete table. So if you have the habit of clearing the buffer after each row change, the buffer size should not be bigger in table buffering than record buffering.
>>>>>
>>>>>>What about of buffer size? It seems to me as strong indication to use row buffering as preferred way (if buffering is used at all).