*snip*
>>Calculated fields definitely have their place, especially in data warehousing and "snapshot in time" systems. I call them evil but they are just sometimes used in ways that weaking the integrity of a system.
>
>Calculated totals in a parent table - that's OK, IMO, specially if enforced by a stored procedure or a bizobject. It's also a historic thing, sort of a log. One thing I've learned from the accountants (among a few other rules) is that once it's printed and seeen by anybody outside the room, a record must never ever be changed. It can be cancelled out by another record, another invoice or whatever, but it cannot be changed. So the totals, once calculated, actually take a life of their own.
>
>The other one was to never calculate the same tax twice. You may get a different result, and stay for hours to see what happened... And actually, you should never total and then calculate the tax on the total. You should calculate tax per item, round each one to cents, store the result and then total the results in the end. It's less accurate, I know, and I complained and tried to prove them wrong - but that's the only way to have the total tax (for the day, for the month, for the sales of one item, for... you name it) match. I've stayed my extra hours trying, I should know.
>
>The really evil calculated fields are those you can rebuild from other fields in the same record. Like, when you have the first name, middle, last, and the composite name. Someone edits one of them, bypassing your checks, and all of a sudden it's wrong. Unless your checks are at the database level - update trigger, for instance.

I stand corrected. I said tax rate but should have said tax.

I believe how tax is calculated is normally subject to local law. Here in Florida, state sales tax is 6% of a taxible transaction. So if you have 10 transactions of .10, .01 would be collected from each transaction resulting in .10 sales tax from 1.00 in sales, however, if you had 1 transaction for 10 items at .10 each, the sales tax collected would be .06 or do you mean that tax for each line item should be calculated and stored based on that line item's portion of the total tax calculated on the sum of all line items in the invoice?

Your example of really evil calculated fields is better than mine. I especially try to avoid calculated fields in my Fox DOS applications due partially to the lack of database triggers and some users preferring to modify tables directly. :(