David,

To test my previous response I did the following:

I placed both a table and view on a form with optimistic table buffering.
I placed a text box for a field from the table (1), view (2), and one (3) that would contain the
value of the table field populated with a SQL statement on the table.

I change the view field and did a table update
TABLEUPDATE(1 , .T., [V_Name])
Then I re-populated the SQL text box.

After the view update the view and table text box had the new value, the SQL text box had the old value.

I then did a table update on the table and re-populated the SQL text box. All three boxes then contained the new value.

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.

-myron kirby-
myronk@flash.net
--------------------------------------------------------------------
>Myron,
>
>Tableupdating the view, commits the changes to the table.
>
>>If you have buffering on the underlying tables can't you go ahead and do a tableudate to the view and not the underlying tables. This way you could do your summary query on the view and still have the capability to revert your changes before they are committed to the tables.