As its name implies, table buffering buffers all of the data in a cursor. If the cursor is closed, an implicit TABLEUPDATE is performed. This can be a problem if you don't control the TABLEUPDATE, because if it's unsuccessful, the user will get a message to revert the changes, which isn't too friendly.
Table buffering is always recommended on child cursors (i.e. displayed in grids). However, one school of thought says to always use Table Buffering (versus Row Buffering).
A good discussion of the relative merits of each type of buffering can be found in the book Effective Techniques
Buffering for views cannot be turned off, nor can it be pessimistic. However, coding can duplicate pessimistic effects.
Parenthetically, in studying for the exam, I found this nugget in help on limiting double errors from triggers, that may find a home in your bag of tricks;
If you handle database errors using triggers, you should turn buffering on. That way, when a record is updated your trigger is called, but the record is not immediately sent to the underlying database. You therefore avoid the possibility of producing two error messages: one from your trigger, and another from the underlying database engine. hth
Contributors: Nancy Folsom
Category Data Buffering
( Topic last updated: 2000.07.23 10:19:26 PM )