Mark,

>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?

If the form just has a view in it's DE, then yes tableupdate( "TheView" ) commits the changes to the table.

Myron is saying to also include the table itself with buffering to the form which will cause another layer of buffering of the data. I don't want that complexity though. I can work around the SELECT issue easier.

>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?).

Still trying to find out why this is the case.

>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.

I told someone else in the thread that SUM does work like the scan loop.