>>>>>>>You could use parameterized table-buffered view as Grid.Recordsource. Then you use CALCULATE SUM... from Grid.Column.Text.InteractiveChange event, assuming that you will restore record pointer.
>>>>>
>>>>>>Edward,
>>>>>>
>>>>>>I haven't tested this, but if you are using a view can't you just run another aggregating SELECT against the view to get column sums? You wouldn't have to save/restore record pointers that way.
>>>>>>
>>>>>
>>>>>The problem here is that Select-SQL will go to the underlying table ignoring interactive changes (no tableupdated yet) in grid.
>>>>
>>>>You can
>>>>Select * from myview
>>>>instead of
>>>>select * from underlyingtable1, underlyingtable2
>>>>
>>>>and the results will show the data from the view, updated or not.
>>>
>>>It was discussed initially few months ago, and it was settled that Select-SQL will go to the underlying table anyway, doesn't matter what is written in FROM clause.
>>>To make this sure, I just tried quick test, and results are still the same: it's going to the table, and if no TABLEUPDATE() issued yet, then result misses interactive grid changes.
>>
>>Before I posted, I did the same test, and found the opposite results. The form is using optimistic buffering, and there were no tables open in the DE except for the view. I placed a grid based on the view in the form, and a button next to it with the code;
>>
>>select * from myview to screen
>>
>>I ran the form, changed a value, tabbed out of the field (this is important!) and clicked the button. The resulting query reflected the changes made in the view. To make sure that the tables did not somehow get updated, I closed the form and restarted it, and the values in the grid had reverted to their original states. Is there a setting that we could have set differently to get such different results?
>
>Strange! Maybe it's version issue (I tried in 3b). I would appreciate other people replies on this topic.

I use 5.0 and select * from myview doesn't give me records in the buffer. The view is on buffering mode 5.