Myron (sorry, David),

Can you please clarify your original "intent". . . I did not catch it as David seems to have in the statement reporduced below:

----- Start copy. . .
>Myron is saying to also include the table itself with buffering to the form which will cause another layer of buffering of the data.
----- End of copy

I would find it helpful.

Thanks in advance,

Jim N


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