Since reviewing several records to get a balance can be slow, I tend to update this automatically - through triggers. In your case, since you have to postpone the updating of the balance, there might be a field of type "L" which says whether a specific transaction has been updated (has updated the grand total) or not - and a process to update those that are more than "x" days old (and mark them as updated).

>Hi,
>
>I have a table of "transaction" entries (deposits and withdrawals) for member accounts. Entries may be voided/reversed, in which case they do not affect the account balance.
>
>I have been thinking that i would STORE the account balance.
>
>Two systems will be accessing the account, creating entries and calculating and displaying the account balance. The first system (Social Security) will be making deposits and withdrawals, and the other system (Provider) will be looking at the account balance, and making withdrawals.
>
>The maximum number of deposits would probably be something like 4x/year...so even after 10 years, we're only talking about roughly 40 deposits.
>
>Now my client wants to, for certain deposits, delay the inclusion of the amount in the account balance, by a number of days (to insure that the deposits paid by checks do not bounce).
>
>I was thinking that i would store an "effective date" in these types of deposit transaction. So that means that we have an "account balance" and an "effective account balance." Eventually either the delayed deposit will become effective, or it will be reversed if the check bounces.
>
>But now i'm rethinking the whole thing....should i be storing the account balance? or just always calculate the "account balance" and the "effective account balance" on the fly. It seems that i DO have to always calculate the "effective account balance" on the fly in any case. Or have a daily automatic routine to check all entries and update the account balance.
>
>Would appreciate any ideas/input. Thanks! J