>Dmitry,
>
>With all due respect, you're taking the wrong approach. Yes, you can do this with a do while or even with (ugh) records based solution.
>Best is to calculate on the fly as I showed you earlier.
>
>By having seperate records for purchases and seperate records for sales, you keep way better track of what is happening and is faster than what you're trying to do now and you can calculate the stock in a single SQL statement of 10 lines.

Almost 20 years ago, our apps were doing this kind of calculation on the fly, so every move out of stock had a freshly calculated price, and any change in the inputs (i.e. correction of a price or quantity in a previous purchase, return to stock, anything that happened) would cause recalculation of prices (sometimes with limitations, as in "can't touch a closed month"), no matter whether it was a FIFO, instant average, monthly average or whichever method. And that was FPD2.6, local network on coaxial cable (probably still 100 megabit), 386 workstations and 486 file server with whopping 8MB running W95 or DOS 6.22, blazingly fast. Nobody even noticed that it may have done the recalculation (including stock update by quantity, price, current value) for all 30 or 50 items that were on the document. And the transaction table had tens of thousands of records, probably hundreds of thousands by the end of the year.

I don't see the need for more speed.