Sorry for my weak neurons. I'm not sure I understand what Myron is saying. I thought that doing a tableupdate update on a view was a one-step process in commiting changes to the underlying table. For example, how does one do a tableupdate on a table lying out there in Oracle or MSSQL world except by tableupdating the view?

And I'd be interested in knowing also if Dave can get a definitive answer about why changes to a view's buffer are not immediately available to a locally exercised SQL statement that is applied to that view (which should be a private copy of locally modified data, no?).

One thing that Dave might do as a workaround is to USE the view cursor AGAIN (would be interesting to know what data was visible in the reUSED cursor), and do a SUM or CALCULATE statement on that data, then close the reused cursor.

>Myron,
>
>Thanks for the additional and that makes sense. But I'm not willing to introduce the complexity of another layer buffering into these child forms.
>
>
>>I believe that if you have a view and its table with buffering and you make a change to the view that the change is made to the view's buffer. Then if you do a specific TABLEUDPATE on the view that the view's buffer is committed to the table's buffer. Only when you do a TABLEUDPATE on the table does the table's buffer get committed.