Thanks muchly, Myron!

I *had* hoped that you were saying that the view was all that was really necessary (the table having to be there for the view anyways) but you distinctly mean to have the table opened separately for this mechanism to work.

I would expect that there *could* be trouble in the future with relaince on such a mechanism - there may be a reason why "they" haven't told us their design intentions as far as buffering and actual table updating is concerned. Maybe they have plans to "optimize" these things in the future.

Thanks again,

Jim N

>Jim,
>
>Originally there was a question of how to get a summary total from a view without the data being fully committed. I inidcated that if both the view and table had optimistic table buffering you could committ the changes to the view which places them in the buffer of the table. You could then do a SQL-Select on the view to get the totals you need. If you needed to revert your changes you still could do a tablerevert on the table. The discussion continued on whether a tableupdate to the view would automatically commit the changes to the table. Many times I have both the table and the view in my DE. My save routine cycles through and does a tabelupdate on all the views and then cycles through all the tables and does a tableupdate.
>
>-myron kirby-
>myronk@flash.net
>-------------------------------------------------------------------------
>
>
>>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