Thanks for your reply, R.P.Rozema.
Isn't the essence of your problem that you are trying to calculate off of percentages of a volume per shipment? In other words, shouldn't you store absolute quantities of the components inserted instead of percentages of the received shipment? I.e. from the volume and percentages of a receipt you can easily calculate the absolute quantities of each component and merge those into the quantities already there (very much like the liquids themselves). Calculating the percentages over the contents over the entire tank or a partial shipment taken from it will be an easy task given the volume of the tank/shipment and the absolute quantities in your table.
Yes, you are correct. If I could store the running balances of the individual components at each transactions, my problem would be solved. But, users are not perfect, and they often discover that they made a mistake (or a receiving document was incorrect) and six months ago the product that came in as 100% (1000 GA) of Napa Valley Zinfanel was actually only 75% Napa Valley Zinfandel and 25% Bakersfield Merlot. All the component qtys stored for the last 6 months are incorrect once the mistake is discovered. In reality, I don't use a cursor for this. We have a nightly batch job that builds the running totals beginning from the earliest date that any transaction was changed. This data is stored in a data warehouse and is growing exponentially large, requiring more and more database space. At one time we did use the cursor approach but the performance was unacceptable, which is why the data warehouse method was developed. I was hoping to find an alternative to the data warehousing approach (users have to wait till the next day to get the most accurate data, and if we have to make a correction farther back in time than, say, 1 year, the process takes many hours) and since the cursor approach already failed, I knew that was out of the question.