Is missing trn:currency clause legal?

[Donald Allen]

I recently filed a bug report (609583) regarding an issue that came up
when  testing the sql backend. The report referenced 2.3.8, but I've
been working with the svn trunk and it exhibits the same behavior.

Summarizing the issue, I open a copy of my current gnucash (xml) file
with the svn trunk version of gnucash and a quick check of the numbers
on the Accounts tab and the transactions in my checking and savings
account look fine. I then do a 'Save As' to a sqlite3 file and that
completes. Accounts still look ok. I then restart gnucash and the
Account tab numbers are bogus and my checking account is truncated --
no transactions after 2006-05-04.

With help from Phil Longstaff and John Ralls, I picked through this
with gdb today. The truncation is due to an assertion failing in
gnc_sql_save_commodity, specifically

g_return_val_if_fail( pCommodity != NULL, FALSE );

gnc_sql_save_copmmodity is being called from this line in save_transaction:

is_ok = gnc_sql_save_commodity( be, xaccTransGetCurrency( pTx ) );

The current_currency entry in the Transaction struct pointed to by pTx
is zero, which leads to the assertion failure. If you look at this
transaction in the xml file, it does not have a <trn:currency> clause,
which I presume leads to current_current being zero in the internal
representation of the transaction. It's the only such transaction in
my gnucash file. Thinking that perhaps this was due to a bug in the
4-year-old version of gnucash I used to enter this transaction that
might have been fixed, I tried opening the xml file with the svn trunk
version of gnucash, modified the transaction by changing the amount,
and wrote out the xml file again. I looked at the xml file in emacs
and the <trn:currency> clause is still missing, but the new amount is
now present. Deleting and re-entering the transaction with the current
version *did* result in a transaction that has the  <trn:currency>
clause and thus does not cause the assertion to fire and truncate the
data written to the sqlite3 file.

So here's my question: is the transaction without a <trn:currency>
clause mal-formed? If it is mal-formed, then more work is needed,
because the current version produces such transactions under certain
circumstances: it did so when I *modified* the transaction from 4
years ago and I don't think my deletion-reentering experiment proves
that it's not going to do this with a new transaction, since my newly
entered transaction and the one four years ago were certainly entered
with different UI gestures, so I think it's possible that whatever
caused this 4 years ago could still be lurking in the code.

And regardless of whether it is mal-formed or not, the sql backend
needs to do a better job of dealing with this situation -- it
currently fails silently. You only find out that this has occurred
when you restart gnucash and your numbers are bogus. I will work with
Phil when he returns in March to fix this (I don't know enough about
the gnucash environment to do better error notification through the
GUI  time-efficiently myself).

BTW, I should note that mal-formed or not, this transaction caused no
trouble with the stable versions of gnucash to-date (certainly there
have been no complaints about the validity of the xml file). I should
also note, for the record, that my gnucash file has never been written
to by anything other than gnucash.

/Don