Requirement: Display the sum of a calculated column in the footer of continuous form and keep the column and the sum updated when rows are updated. The recordsource can be a stored procedure (preferred), selection from a view, or any other method that will work. Back-end server is M SSQL 2000, though it will in a matter of months be upgraded to SQL 2005
Issue: Access ADP manages updates and refreshes behind the scenes. Because it queries the "unique table" directly to refresh updated values and skips the stored procedure entirely, it does not update the calculated column and thus does not update the sum expression. A requery of the entire recordset is not acceptable because then row selection and form scroll position are lost and it generates an additional hit on the database.
Setup:
See the attached code to create a SQL Server database, two tables, and a stored procedure. See the attached file for a working ADP connected with integrated security to "(local)" which demonstrates the problem (rename .txt to .zip and extract). Or use the instructions in the attached code to reproduce the ADP.
To reproduce the problem:
Open ExampleForm. See that the sum of the queried rows is displayed in the footer. If you change Number1 or Number2, the CalcTotal field is not updated and the sum is not updated.
Don't worry about the given form and subform's ability to add new records or other functionality, as I have that covered.
Please provide a solution that doesn't store the calculation in the database (or give good reasoning why this denormalization would be acceptable and how data integrity would be maintained). A calculated field is okay, but performance also matters: a calculated field that uses a function will be very slow, whereas a query that does the same calculation inline will be faster. Keep in mind potential reporting scenarios with where clauses using the calculated value.
Ideas:
- Create a WITH VIEW_METADATA view and make the SP select from this: in tests this failed because the recordset was not updatable, even with SCHEMABINDING and a clustered primary key index on the view. Maybe I messed this up.
- Calculated column in table. I am trying to avoid a function which would be required in order to pick up the multiplier value from the main table.
- Database redesign: suggest a design that reproduces the conceptual layout that doesn't suffer from the same problems.
I am open to better ways to link parent and child subforms, but a SQL profiler session to see what Access really does behind the scenes is necessary to help gauge the performance and elegance of the result.
Start Free Trial