https://bugs.kde.org/show_bug.cgi?id=473223
--- Comment #16 from Thomas Baumgart <tbaumg...@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.