Somehow gnucash 2.x managed to write an transaction with a date-posted element that seems to correspond to the value 0 into the XML file. gnucash 3.2 can open the file without problems. However, if anything is changed and the file is written back, gnucash can no longer open the file again, claiming a XML parser error. Comparing the original file and the newly written one, then I can see in the diff, that in that transaction the date-posted element has been removed: ============== %< =============== ~/tmp/mem $ diff -u Finance.gc2.20181025201900. Finance. --- Finance.gc2.20181025201900. 2018-11-05 01:19:42.197548980 +0100 +++ Finance. 2018-11-05 01:19:48.588632156 +0100 @@ -733631,9 +733631,6 @@ <cmdty:space>CURRENCY</cmdty:space> <cmdty:id>EUR</cmdty:id> </trn:currency> - <trn:date-posted> - <ts:date>1970-01-01 00:59:59 +0100</ts:date> - </trn:date-posted> <trn:date-entered> <ts:date>2013-01-26 19:28:12 +0100</ts:date> </trn:date-entered> ============== %< =============== It seems the XML parser validates the XML when opening the file and the missing elements causes a failure. As result, the data is lost for normal users. Adding that element with a proper formatted date again will enable gnucash again to read the file.
I understood from your email on gnucash-user that you'd found this to be the case with 3.3 as well. Is that correct? In other words, did you load your 2.6.x book in 3.3, edit something, save it, and it failed to open? If you meant that 3.3 was unable to the book saved in 3.2 then that's a different issue.
Yes, gnucash version 3.3 behaves like version 3.2 if feeded with the original file written with 2.7.4. making a minimal change, save it, and it fails to load.
Turns out I was wrong about the invalid slot-value, it was the culprit after all. This is fixed in git for GnuCash 3.4.
OK. I still wonder, how that one was created in first place. Nevertheless, it's good to know, that it does no longer break the complete data. Thanks for investigation.
In the first place you had a typo, entering 201-01-02. That was a valid date in GnuCash 2.6 but isn't in GnuCash 2.7 or 3 and several users have been tripped up by similar date errors. When you upgraded from 2.6 to 2.7 last year the trn:date-posted value was changed to 0 but the KVP value wasn't.
