> First of all: Thank you guys for all the inputs!!
> So, I see that nobody uses a separate table mantained with triggers to
> do that,
> which make think I won't have any performance issues if I construct the
> current
> account "on the fly". I Like the idea of "closing a year" but some
> customers are
> reluctant to do that, so I would use it as a general rule for al my
> systems.
>
> May I ask a couple more questions?
>
> > Views can be used for the balance of which you speak and they can can
> be
> > very fast.
> > Alan
>
> I can't figure out how can make it with a view. I mean how a view would
> help me
> to show the balance column, which depends on the previous record. May I
> have an
> example, please?

a view won't give you running balances, only ending balances
I can only do running balances on the client and it requires all records
being brought over which I try not to do. I stick with ending balances only
where I can.
Alan

>
> > Two possible approaches to calculating the running balance per record
> > that you could look at are:
> > a) use a 'selectable stored procedure' (& calculate the running
> balance
> > balance per record therein),
> > b) use the caller (Delphi, VB, Crystal Reports etc) to calculate the
> running
> > balance component of the query.
> > HTH,
> > John
>
> I think I will use a SP, because if I calculate the balance on the
> client side
> and want to show it in a non unidirectional query (ie: in a grid) I
> don't know
> how to calculate the balance. I imagine I can have a calculated field
> to select
> the previous record and take the previous balance from there, but I
> wouldn't
> know how to do it nor like the idea! Am I right? or there is a "proper"
> way to
> do that?
>
> Thanks again guys!

If you use client side sorting, then the SP method of running balances are
broken.
Alan