1.8.2: CRITICAL errors and Warnings

[Derek Atkins]

Randall Hopper <listaddr at charter.net> writes:

> Derek Atkins:
> 
> Thanks for the reply.
> 
> Ok, I understand what you're saying about the format not having changed.
> However, if the format hasn't changed, the constraints and restrictions on
> constructs in the format have (which I would suggest is part of the format
> definition).  

I'm sorry but I have to respectfully disagree.  The fact that 1.6.x is
violating the data constraint without complaint does not imply that
the data format changed, nor is it a bug in 1.8.  This is a bug in 1.6
(being too liberal).  This is not a format change.  It's not even a
constraint change.  It's a verification change, and 1.6 was buggy in
not verifying the data integrity properly.

> If I do a "Check and Repair -> All" in 1.6.6 it's satisfied
> with this database.  I guess I'll just stay with 1.6.6 until this is all
> better understood.

Well, I was suggesting you run the "Check and Repair" from 1.8, not
1.6.  1.6 clearly is not verifying the transactions properly.
Sticking with 1.6 is not the answer, because 1.6 is never going to be
changed, and we are not going to relax the constraint verification in
1.8 (because it results in broken data files like you have).

Your best bet is to move to 1.8 as soon as possible and fix the broken
transactions, either via Check and Repair or, if that does not
suffice, deleting and re-entering the broken transactions.

> I would be willing to write python XML transformation script to carefully
> migrate this database to one compatible with 1.8.x, if I had a precise
> definition of the syntax, including constraints.  Any pointers would be
> appreciated.

You could do that, but it shouldn't be necessary.  Again, if you could
figure out how you created the broken transactions it would go a long
way towards helping track down this problem.  How did you enter this
atransaction on May 2?

-derek

> Thanks,
> 
> Randall
> 
>  |Fair enough..
>  |
>  |> But here's one of the transactions.  As you can see -- no trn:currency.
>  |
>  |not only no trn:currency, but only a single split!  This is an
>  |unbalanced transactions.  How was it created?  It's certainly going to
>  |cause problems.
>  |
>  |> Why?
>  |
>  |I don't know.  How was this entered into the system?  You entered it
>  |on May 2, dated April 11.  But it's not balanced..  I don't even know
>  |how you entered it into the system.  You should probably run the
>  |"Check and Repair" function.
> 
>  |> Right, or the GnuCash importer just has a bug related to importing older
>  |> files.  1.6.x has been happy with it for over a year.
>  |
>  |You still don't understand.  There is no "importer".  The file format
>  |HAS NOT CHANGED.  It's been extended, and new datatypes added, but as
>  |far as 1.6 data is concerned, it's the SAME CODE as 1.6 for reading in
>  |the data files.  However, what has changed is the verification steps
>  |for bogus data.
>  |
>  |The fact that 1.6 is happy is irrelevant.  It's probably a bug in 1.6!
>  |Your data file is broken, and 1.6 did it.  I don't know why, but
>  |that's the problem.  A check-and-repair might help, but honestly I
>  |have no idea HOW you could get a transaction without a currency....
>  |It just shouldn't be possible, unless there is some bug in 1.6.  The
>  |fact that the transaction is not balanced implies something else weird
>  |going on.

-- 
       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