Reports and the root account

[Phil Longstaff]

On March 19, 2009 12:40:27 pm Derek Atkins wrote:
> Hi,
>
> Phil Longstaff <plongstaff at rogers.com> writes:
> > While doing some testing on the sql backend, I noticed that when I run a
> > report (e.g. Balance Sheet), the report system attempts to query all
> > transactions for the root account.  The sql backend tries to do a
> > xaccAccountLookup() on the guid in the qofQuery, and fails when it
> > returns NULL.
> >
> > I could detect this and fail more gracefully i.e. ignore this account,
> > but I think it should be handled in the report system.  I don't plan to
> > address this right now, but can log this in bugzilla if no one else wants
> > to look at it in the near future.
>
> Why do you not have the root account GUID in the SQL DB?

The root account GUID *is* in the db, but not as an account.  Instead, there 
is a books table with 3 fields: book guid, root account guid, template root 
guid.

The problem is that a during split-query processing, xaccAccountLookup() 
returns NULL when passed the root account guid, and the report is requesting 
that all transactions for the root account be loaded.  Since I use 
xaccAccountGetMark() and xaccAccountSetMark() so that subsequent queries for 
an account's transactions are ignored (since the transactions are already 
loaded), these routines log CRIT messages when passed NULL (GNC_IS_ACCOUNT 
fails).

I'm looking for the best solution to this.  I can ignore a query if 
xaccAccountLookup() returns NULL.  I can ignore a query if the account being 
queried is the root account (which will have no transactions).  The report can 
be changed to *not* try to load the splits for the root account.  At this 
point, you're getting the 1st solution with a CRIT message in the trace log.

Phil