[kmymoney] [Bug 473223] Data lost on kmymoney-master-2001-macos-clang-x86_64.dmg upgrade

[Thomas Baumgart]

https://bugs.kde.org/show_bug.cgi?id=473223

--- Comment #16 from Thomas Baumgart <tbaumgart at kde.org> ---
kmymoney-master-2001-macos-clang-x86_64.dmg is pretty recent. The changes that
were made in between are not relevant for this problem.

The file structure is OK, otherwise 5.1.3 would complain. Also, looking at the
tail of the files shows that it is not truncated. Leaves the point, that the
number of transactions shall be 21720 but shows 21698. Well, 22 difference. Not
sure where that may come from.

A gut feeling tells me, that the XML reader stops processing data too early.
That may be caused by content in the data file that is not stored according to
the strict XML specifications. The old (<= 5.1.3) XML reader simply reads the
data but the new one (>= 5.1.80) may have stumbled upon it and simply stopped.
Another explanation would be, that accounts exist that reference an unknown
security. As accounts are loaded before the transactions and securities after,
they are not loaded properly (better at all) and cannot be found in the process
of finishing the load operation (consistency check). That is when messages like

"Account" "A000351" "BPFCU-CD-2747 6 month 12/9/23 " Security 'E000072' not
found.
/Users/packaging/Craft/BinaryFactory/downloads/git/extragear/kmymoney/kmymoney/mymoney/mymoneyfile.cpp:3175

are generated. That also explains, why there are no further messages when
loading the file after loading the model T (transactions). It usually looks
like this:

:
:
Model for "G" loaded with 5 items in 0 ms
Start verifying account hierarchy
End verifying account hierarchy
Model for accounts loaded with 214 items in 4 ms
Model for "T" loaded with 24195 items in 137 ms
Model for parameters loaded with 6 items
Model for schedules loaded with 82 items in 0 ms
Model for "E" loaded with 4 items in 0 ms
Model for currencies loaded with 184 items
Model for prices loaded with 242 items in 0 ms
Model for "R" loaded with 53 items in 0 ms
Model for "B" loaded with 6 items in 0 ms
:
:

The model load operations are all triggered by the XML reader. BTW, the number
shown when loading the journal model (T)  is the number of splits not
transactions. We need to figure out at which transaction it fails (sounds easy,
but may be not).

Once more: make sure to have a good backup copy of your data before you start
changing things!!! Or simply work on a temp copy. You know what I mean

First let's convert the .kmy to .xml file so that we can look at it. This is
the sequence to do it:

cp 9gwengood4.kmy 9gwengood4.kmy.Z
zcat 9gwengood4.kmy > 9gwengood4.xml
rm 9gwengood4.kmy.Z

On Linux, the tool xmllint can be used to analyze the content of the XML file
and check for errors. I don't know, if that is available for MacOS or if there
are other tools to verify an XML file. Does that show any errors/problems?

-- 
You are receiving this mail because:
You are watching all bug changes.