It's been rumoured that Kevin A. Foss said:
>
> On Sun, Dec 26, 1999 at 11:46:52PM -0600, Christopher Browne wrote:
> > On Fri, 24 Dec 1999 16:37:49 GMT, the world broke into rejoicing as
> > Grant Likely <[EMAIL PROTECTED]> said:
> > >
> > > However, I've noticed that if I set the date range to show all my
> > > transactions (about 6 months worth), the register slows down
> > > completely.
This is probably a GUI 'bug' and needs tweaking. I've often thought of
running performance profiles to see whazzup.
> > > Is there any way to modify the display so that it only
> > > loads the transactions from the engine that it actually need to display?
scrolling? Having a scrollable area tends to complicate this kind of
on-demand loading, and tends to make scrolling slow. Rather than
picking a solution just yet, I'd say its better to see where the CPU
cycles actually went, and see if that can be fixed.
> [...snip...]
> > In an SQL database, one might do this via something like
> > select sum(value) from data_table
> > where account='This Account' and
> > eff_date < '1999/11/15';
> > and use the result as the opening balance.
Typically, the opening balance would be the balance that was last
recorded when the prior years/quarter's books were closed. That info
would be 'pre-computed' and stored with the account, rather than computed
on the fly.
Also, my understanding of how 'real' sql systems handle balance info is
that they store the 'ledger balance' as part of the transaction. This
solves two problems:
-- use of sql databases that don't support 'select sum(value)' type
queries.
-- Accounting glitches and wackiness when queries are made against
databases that are also being updated, and/or poorly formulated
queries. This is an accounting 'paranoia factor'
> On a vaguely related note -- as more of a user of GnuCash right now
> than anything, are there any plans to implement a way to separate out
> data for years. E.g., I would like to be able to keep a running
> register with cumuluative up-to-date statistics for all of data-time,
> but also be able to separate out that I spent $X on rent in 1999. Maybe
> this is something more for the reporting end of things, but I wouldn't
> even mind a running result on the bottom of a register for net
> gain/loss for that year next to the total. That last bit is just in
> the throwing out of ideas category. What made me think of it is that I
> would like something on the idea of the above SQL code except eff_date
> would be checked against being on or after the user specified date.
Yep, part of what you talk about is that gnucash needs to implement
'books' that are closed at ends of quarters and years, and part
is about creating a good report infrastructure.
I think these are both high priority items.
--linas
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
