>In my VFP app, I have a certain important table that is the header table for what we call a Job. Each Job will have many collections of records in various other tables that are associated with it: Time records, Material records, Invoice records, etc. So, the data is fairly well normalized and granular and that is good. However, the original architect of our system decided to keep track of the totals of each of these collections in its own field in the main Job table so that he could easily display or report things like "Total Material Cost" or "Total Labor Cost" or "Total Invoiced Amount", etc. So, all the forms and methods that manage the individual related collections, are also burdened with keeping the reference totals in the Job header table up to date. Kind of a nightmare, and creates a lot of coding that really should not even be necessary. And, despite all the best coding effort I can muster up, the reference totals are sometimes not correct, so I have made another maintenance prg to audit and correct the incorrect data.
>
>Am I right that this is a classic bad example of how to manage these reference totals? The values are indeed needed often throughout our system, but I am convinced that this is a bad way to do it.
>
>Now then, before I get too far into reworking how this is handed in my system, would some of you smart folks please tell me how you handle this common issue.

I believe it makes sense to store these totals, for performance reasons - if you need to quickly access the totals, often. Beware that the totals, for some reason, may get out of synch with the original data - it may be convenient to not only update the totals with a trigger in the child table, but also to have a separate procedure to update the totals globally, on request.