[kmymoney] [Bug 410994] Losing transactions after 8000+ DB to KmyFile

[Ralf Habacker]

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

--- Comment #14 from Ralf Habacker <ralf.habacker at freenet.de> ---
(In reply to Ralf Habacker from comment #12)
> 0|A000331|2019-07-08|T000000000000008308
> 1|A000291|2019-07-08|T000000000000008308
> .. 
> 0|A000331|2019-07-10|T000000000000008311
> 1|A000284|2019-07-10|T000000000000008311
> 
> It looks to me that exporting to an kml or xml file from a sqlite database
> is also broken independently from an import into a sqlite database.

The export fails because it expects to have a linear split order without any
missing entries, but the splits returned from the query on kmmSplits do not
include splits for transaction T000000000000008309 as shown below: 

0|A000331|2019-07-08|T000000000000008308
1|A000291|2019-07-08|T000000000000008308
0|A000344|2019-07-09|T000000000000008310
1|A000330|2019-07-09|T000000000000008310
0|A000331|2019-07-10|T000000000000008311
1|A000284|2019-07-10|T000000000000008311

Therefore the code iterates to the end of all splits (because it do not find
the requested transaction number) and cannot process any further splits.

While this problem is solvable (skip any transaction whose transaction number
is lower than the transaction number of the currently processed split and then
notify the user that these transactions could not be exported) this does not
change the basic problem that the sqlite database is inconsistent and we need
to see where it happens.

-- 
You are receiving this mail because:
You are the assignee for the bug.