>Hi,
>
>I am implementing frmDEGridNav2Pages using a buffered (5) view cursor for input. The underlying table is buffered too.
>
>When click Save button while adding or modifying a record the buffer does not seem to be posted in either the cursor or underlying table. I did a trace and it would seem that the transaction got fully commited.
>

The problems are probably the result of buffering both an updatable view and the underlying tables it uses. Since all queries and aggregations are run against committed data, double buffering causes lots of problems with requery- and refresh-related errors from users that end with "...but if you close the form and the go back in, the right stuff is there."

Double buffering results in some fairly annoying and apparently random behaviors in your forms when adding records through a view, especially where a form has more than one view that reference the same table. When both a view and the underlying table are buffered, changes to a view require two independent TABLEUPDATE() operations to occur - the first, done on the view, commits the view's changes to the table's buffer, and the second, done on the table, commits the changes in the table's buffer to the physical table. If you don't make both TABLEUPDATEs, or you TABLEUPDATE the table before the view, the results are confusing at best.

You can change your Save logic to explicitly issue both commands, and deal with the possible results of failures in both calls, especially troublesome using optimistic strategies, but I'd recommend avoiding the problem entirely by buffering the view but not the underlying tables. It's easier to code and less difficult to debug.

Of course, if you own the local drugstore, YMMV, since using multiple layers of buffering will usually boost sales of headache pills, antidepressants and anxiety medications before it is fixed. < BEG >