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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
