>I have an electrical bill calculation form. In one field the consumed units are stored and then they are multiplied by 4 to give the amount due to the consumer. Now what if the rate of the electricity goes up and the unit is 5$. How will the user change the rate at his own discretion? Also if he changes the rate today from 4 to 5 , the previous records will also be modified at the new rate. How can the user change the value for today , without modifying the previous records?

Welcome into the inflation nightmare. I've been through some 300,000,000% a month, so trust me, I know what I'm talking about.

You actually have a quantity and price to give the amount. The price should be copied to the same record where the quantity is, and their product as well - calculate it once and never recalculate. If you recalculate, you'll lose all day hunting cumulative roundoff errors, and won't catch them ever. You don't have to retype the price every time, though - you may have a default value for it, and have the user just confirm it or have another form where the default price can be changed. Also, be prepared to think of billing 17 days of a month at one price, and the other 13 days at another price - your billing routine may have to run more than 12 times a year.

Each record should be a self-contained calculation, and keep all the info which is necessary to reconstruct a bill. If you have something of a nice inflation, you may expect the laws of rounding to apply soon, so I'd also recommend to keep somewhere (field in the parent table of the bills) a copy of the number of digits to round to - normally, it would be 2 in most of the countries most of the time, but I've seen it go up to -6 (our currency unit was one million dinarsby the end of 1993).

And... yes, be prepared to rethink the lengths of your numeric fields, but even setting them to the maximum may not be enough sometimes - I've seen fox losing lower four or five digits in lengthy calculations, because some totals exceeded its precision - subtracting two 19-digit numbers loses the rightmost three or four digits of them.

I hope you don't need this.