https://bugs.kde.org/show_bug.cgi?id=410994
--- Comment #14 from Ralf Habacker <ralf.habac...@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 watching all bug changes.
