Troubles with reports in current SVN

[Mike Alexander]

--On March 19, 2006 11:03:06 PM +0100 Christian Stimming 
<stimming at tuhh.de> wrote:

> - The text reports are *significantly* slower than in 1.8; e.g. the
> current  "balance sheet" takes 8 secs with the standard options and
> in 1.8 this was  3.5 secs; same for the "account summary"; the
> current "income statement"  takes 12 secs and it used to take 5. This
> is too much. I can't believe  doubling the runtime is technically
> required here -- I know the 1.8 reporting  code wasn't optimized for
> efficiency at all, but it nevertheless gave the  correct values. I
> can't see what new features in SVN would justify this  significant
> slowing down here. Especially since a response time of 3-4 secs  can
> still be tolerated by the user, but 8-10 secs is really too much.
> IMHO  this whole new reporting should be up for discussion here,
> potentially  including a revert to the 1.8 status.

I tried the balance sheet report in 1.9 yesterday for the first time 
and it appears to be not only slow, but also broken.  I tracked it down 
to the fact that gnc:account-get-comm-balance-at-date sometimes returns 
the wrong value.  This sounds like a pretty serious bug, but I'm 
reasonably sure I'm right.

It uses a query to get all the splits in an account that are not later 
than the date given, then sorts them by date posted and default sort. 
It then takes the balance from the last split.

This hasn't changed since 1.8, what has changed is the sort.  If two or 
more splits in the account happen to be all on the date specified (so 
the first sort key is the same for all of them) then it seems to be 
somewhat random which one will actually sort last. 
gnc:account-get-comm-balance-at-date wants the last one entered to sort 
last but this doesn't always happen.

This problem affects other reports too.  For example the account 
summary report shows the wrong balance for the same account.

I'll file a bug report unless someone knows immediately why this 
happens (or why I'm wrong).  I have a test file that demonstrates this 
problem if it's needed.

-- 
Mike Alexander           mta at umich.edu
Ann Arbor, MI            PGP key ID: BEA343A6