GNOME Bugzilla – Bug 611853
Entering a 2-digit year in the opening balance tab results in "Parsing Error"
Last modified: 2018-06-29 22:36:08 UTC
Created attachment 155269 [details]
I entered data into GnuCash for the first time today. I saved all my data then closed the application. When I tried to open it again using bin\gnucash.cmd I get this error: "There was an error parsing the file C:\Documents and Settings\jtripp\My Documents\Julie's\GNUCash\TrippFinances". I cannot find any error logs to try to debug the issue myself so I have attached TrippFinances. Hope you can help. :-)
There's a single quote in your path to your data file. I'm not GnuCash can handle that.
Can you try to create a gnucash file in another directory (like C:\temp) for testing, and see if that works ?
I copied the folder to C:\GNUCash but still I get "There was an error parsing the file C:\GNUCash\TrippFinances."
Thank you so much for your help so far. :-)
One more try: can you create a NEW file in C:\GNUCash ?
It is possible GnuCash couldn't write properly to the TrippFinances file while it was in the path with the single quote in it. In that case the TrippFinances file would be invalid for GnuCash.
Oh, and by the way, which version of Windows are you using ?
I'm using Windows XP Pro SP3.
Later today I will try to recreate my file from scratch in C:\GNUCash. Hopefully this will fix the issue.
Created attachment 155394 [details]
GNUCash File New Dir
I tried to duplicate my last GNUCash account from scratch at C:\GNUCash, but I'm still getting "There was an error parsing the file C:\GNUCash\TrippFinances2." after I try to re-open.
If I save without entering data then close and re-open it's fine, but after I enter data I get this parsing error.
I have attached my new file. :-\
I can confirm this even on linux with your data file.
For the record, after the parsing error this is printed in gnucash.trace:
* 11:52:15 CRIT <gnc.io> [dom_tree_handlers_all_gotten_p()] Not defined and it should be: trn:date-posted
* 11:52:15 CRIT <gnc.io> [dom_tree_generic_parse()] didn't find all of the expected tags in the input
And this transaction is printed on the console:
<ts:date>2010-03-05 14:15:56 -0800</ts:date>
So for one reason or another there is an invalid transaction in the data file. This transaction is lacking the mandatory trn:date-posted field.
The transaction is between the Opening Balances account and the Sears Credit Card.
Julie, how exactly are you entering this transaction ? There are many other transactions in the file that are just fine. So is there something that distinguishes this transaction from the others ?
In any case it seems I was wrong about the quote in your path. If the error is reproducible in C:\GNUCash, the quote is obviously not the cause.
Julie, how exactly are you entering this transaction ? There are many other
transactions in the file that are just fine. So is there something that
distinguishes this transaction from the others ?
I'm not entering this in differently than the others. I did not receive any kind of error when entering it. For the new account with an opening balance I enter the opening balance on the second tab.
Since you said the error was between Opening Balances and Sears Card then I have a theory that the problem is with Opening Balances. I have yet to test this since I have been rather busy. But my plan is to create two new accounts, one with an opening balance (for an account created after the initial creations) and one without and see if that's the problem.
I have the same issue as Julie. I don't know if this could possibly have anything to do with it, but I had installed Strawberry Perl in between the last time I used Gnucash successfully. When I tried to open my gnucash account today and it failed I saw that my Strawberry Perl ran something in a dos window as Gnucash was loading as if Gnucash had called it.
Is that crazy?
I tested my Opening Balances theory and it seems to be the problem. I will continue entering data in a new account with opening balances and see what happens.
I don't have Strawberry Perl on my computer.
I can confirm Julie's theory. I recently started using GnuCash 2.2.9 (on Windows)
and didn't at first notice the opening balance tab in the new account creation
dialog. Once I did notice the tab and used it to enter the opening balances of
some new accounts, I'd start seeing the same parse error as reported above.
Thanks to this issue I was able to fix the troublesome file by manually entering
the missing trn:date-posted elements. Everything seems to work fine if I don't
use the opening balance tab, and instead enter the opening balance just like
any other transaction.
Since my last comment I have been using GNUCash every day without any trouble by not entering the opening cash balance in the create a new account dialog. Now that we have figured out this is more than likely the cause, hopefully it will be easier to fix the bug. :-) Thank you for your efforts.
Thank you all for the feedback. I'll mark this as a valid bug report to be fixed.
Alas, I can't reproduce this behaviour on my Windows Test machine...
I'm running Windows XP Home, Service Pack 3, Dutch version.
Could you provide me with very detailed steps of a way you can consistently reproduce the parsing error ?
- open a GnuCash data file
- choose "Create new account"
- enter this information (like what type, name, parent account,...)
- what do you enter on the opening balances tab
- ... anything you do until you get the parsing error.
And could you attach the gnucash.traceXYZABC file after the parsing error (see
http://wiki.gnucash.org/wiki/Windows#Error_messages.2C_Trace_file to find this file) ?
I hope it's some specific combination of actions that results in this crash.
I boiled this down to the following steps:
1. Open GnuCash (I'm using 2.2.9 on Windows Vista)
2. Select File > New > New File
3. Use the default settings in the New Account Hierarchy Setup wizard
(for me they are "CHF" and "Common Accounts")
4. Select File > New > New Account
5. In the General tab, set Account name to "test" and Account type to "Bank"
6. In the Opening Balance tab, set Balance to 1000,00
(comma is a decimal separator in my locale)
7. Select File > Save and save the file as "test.gnucash"
8. Select File > Open and try to open this same file
-> "There was an error parsing the file ..."
I'll attach the resulting file where the troublesome transaction entry can
Note that I get the same result even when I cancel the New Account Hierarchy
Setup wizard in step 3 and use an empty accounts page instead.
Created attachment 157560 [details]
Created attachment 157561 [details]
Trace file from trying to open the above test.gnucash file.
I still can't reproduce with your steps. On my system, the default currency is Euro. If I keep this, I get no problems. I also tried using CHF, but it still gives no parsing error.
The gnucash.trace file you attached gives the same information I already found in comment #6.
As I understand it, the post date is taken from the opening balance tab as well for some reason this step doesn't work on your system and does on others. So let's see if we can find out what's different there.
Can you do the following experiment for me:
- Run your steps up until step 5.
- In step 6, set the opening balance, take a screenshot of the opening balance tab and attach it to this bug.
- Then close close the new account dialog, save and quit GnuCash
- Attach the gnucash.trace file that was generated (BEFORE you restart GnuCash and run into the parsing error again).
Created attachment 157565 [details]
Screenshot of the Opening Balance tab
Created attachment 157566 [details]
Trace file covering the above steps 1-7
Trace file as requested. There's one suspicious-looking entry:
* CRIT <GLib> g_date_to_struct_tm: assertion `g_date_valid (d)' failed
The date "31.3.2010" is what I get by default in the dialog,
i.e. I didn't change it.
BTW, the above date format is correct in my locale and it's also used elsewhere
in GnuCash. I use the same date format when entering normal transactions.
Yes, I agree the date format should be valid. However, GnuCash clearly thinks otherwise (or more precisely, glib does) as shown by your latest trace file:
* CRIT <GLib> g_date_to_struct_tm: assertion `g_date_valid (d)' failed
There is something with the date field in the opening balance tab.
I also noticed for example that in my case this field uses date format dd/mm/yyyy, while the rest of GnuCash uses dd.mm.yyyy.
I'm not sure yet what it is, but I believe this is where the problem starts.
I have been looking on and off at this for a while now. The GnuCash code seems completely correct to me. It depends on a a call to the glib library to retrieve the date from the date field. This call shouldn't fail. The date field is supposed to guarantee that the date entered is proper. This guarantee doesn't seem to work 100% on Windows.
I notice that the development series of GnuCash (2.3.x) uses a more recent version of the glib library. Perhaps it has fixed the problem already. To test this, can you
* download GnuCash 2.3.14 from http://code.gnucash.org/builds/win32/trunk/
* uninstall GnuCash 2.3.9
* Make a backup of your .gnucash directory (this is probably a hidden directory) in c:\Documents and Settings\<username>
* install GnuCash 2.3.14
* Run your steps up until step 7.
* Then quit GnuCash
* Attach the gnucash-xyz.trace.log file that was generated, BEFORE you restart GnuCash (Note that 2.3.14 adds .log to the trace file's name)
* Then try to open GnuCash again and see if you still get the error.
* Uninstall GnuCash 2.3.14
* Restore your original .gnucash directory
* Install GnuCash 2.2.9
The steps with the .gnucash directory are not related to the problem, but this prevents the development version of GnuCash from interfering with some local settings in the stable version.
The uninstall of 2.2.9 is necessary because 2.3.14 won't start properly otherwise (it is installed on top of 2.2.9, but this isn't done completely cleanly, so it fails to start unless the old release is removed first).
I am based in the UK and have had the same problem while trialing 2.1.9.
Have tried on 2.3.14 and still the same.
I think I have isolated the cause.
If when adding the opening balance on the opening balance tab you either enter the date with the calendar or by typing the date with four characters for the year then it is OK. If you type the year with just two characters then although it doesn't flag up an error, you get the passing error when restarting GNUCash.
So far this is 100% repeatable.
Thank you very much. I think you have exactly pin-pointed the cause: if I only use 2 digits for the year, I can also reproduce this on my test machine.
As far as I can see, the bug is actually in libgnomeui, an external library used by GnuCash. But unfortunately it has ugly side effects in GnuCash.
The good news is that this means the opening balances tab is not completely unusable. I see two possible workarounds until the problem is fixed:
1. Use the dropdown menu ("Calendar" in English) to select a date
2. When entering a date manually, make sure you enter a 4-digit year
So how do I fix a file to be able to use it? I will keep note to only enter years as 4 digit, but how do I recover my existing file? TIA.
There is no easy way from within GnuCash to recover your file, because it fails to open.
But if you don't mind manually editing an xml file, you can do as follows:
* Open a copy of your data file in a text editor (Wordpad on Windows, or emacs, kwrite,... on linux)
* If you only see garbage or get a warning the file is unreadable, that means it is still gzip compressed. In that case you have to rename the copy of your data file to <somename>.gz and use a suitable tool to uncompress that file (on linux you could use gunzip, on Windows I don't know off-hand which tool to use, you'll have to consult google)
* Anyway, try to open the uncompressed file in your text editor.
* You should see an xml file now.
* You will have to go through the xml file looking for transactions which are missing a <tr:date-posted> record.
If your file is big, this can look challenging, but on linux there's some help: to know which transaction you are looking for, you should start gnucash from the command line like:
Like this, GnuCash should attempt to open the copy of your datafile. This will still fail, but it will print the invalid transaction on the command line. From this output, you can take the transaction's guid and search for that in your text editor.
Once you have found the invalid transaction, add a <tr:date-posted> record. For an example, just look at another transaction in the same file.
Save your changes and try to run GnuCash again. If it still fails, it should be printing you the next transaction that was invalid, and your can repeat the process.
Once all transactions are fixed, GnuCash should be able to open your corrected data file and you can continue to work.
*** Bug 626910 has been marked as a duplicate of this bug. ***
*** Bug 611020 has been marked as a duplicate of this bug. ***
This problem has been fixed in the development version. I have replaced the date entry field on the opening balance tab with the same code as used in the register. Aside from fixing this 2-digit issue, this also adds keyboard navigation (+/- in combination with shift, alt or ctrl to jump one day, one month, one week or one year in the date field).
The fix will be available in the next major software release. Thank you for your bug report.
*** Bug 669061 has been marked as a duplicate of this bug. ***
Since GnuCash 2.6 may still be a while, I have fixed this for 2.4 as well in r22239.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=611853. Please update any external references or bookmarks.