Is missing trn:currency clause legal?

[Donald Allen]

On Mon, Feb 22, 2010 at 4:21 PM, Derek Atkins <warlord at mit.edu> wrote:
> Hi,
>
> Donald Allen <donaldcallen at gmail.com> writes:
>
> [snip]
>> So here's my question: is the transaction without a <trn:currency>
>> clause mal-formed?
>
> Yes, it is 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.
>
> This is not actually true. The currency is only touched at transaction
> creation time.  It is not retouched later.  SO the fact that you
> modified a 4-year-old transaction has no bearing on the issue.
> Modifying it will not reset the currency.

Ok, understood. So my case that the current version might still
produce transactions without trn:currency clauses is weaker, since I
haven't given an instance where it does this. But the fact that my
re-creation of the problem transaction was properly formed doesn't
prove that it *doesn't* still have this bug. If I feel ambitious, I'll
search the last 4 years' changelogs to see if I can find a fix that
sounds like it relates to this.

>
>> 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).
>
> Agreed, it should be more vocal about failures!  In particular it should
> at LEAST output something to gnucash.trace!

It already announces the assertion failure in gnucash.trace. That's
great for debugging, pretty useless for an ordinary user. The user
needs to be told about this via the UI.

>
>> 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.
>
> This is just luck, and the fact that the xml data processor is more
> forgiving of errors.
>
> Can you try to run a Check & Repair to see if it fixes the issue?

I did and it did (with gnucash 2.2.9). It didn't take very long,
either, and my xml file is over 20 Mb uncompressed. Perhaps you should
consider automatically running Check & Repair after N restarts of
gnucash, just as fsck is run after N clean reboots that mount an
ext2/ext3 filesystem.

/Don

>
>> /Don
>
> -derek
> --
>       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>       Member, MIT Student Information Processing Board  (SIPB)
>       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>       warlord at MIT.EDU                        PGP key available
>