I got today the update from 5.1.3 to 5.1.92 on my PC. Unfortunately when I start it I get the following error: Error in function QMap<QString, MyMoneyPayee> MyMoneyStorageSql::fetchPayees(const QStringList&, bool) const : reading Payee Driver = QMYSQL, Host = 192.168.0.12, User = marco, Database = KMyMoney-CHF Driver Error: Database Error No : Text: Error type 0 Executed: SELECT kmmPayees.id AS id, kmmPayees.name AS name, kmmPayees.reference AS reference, kmmPayees.email AS email, kmmPayees.addressStreet AS addressStreet, kmmPayees.addressCity AS addressCity, kmmPayees.addressZipcode AS addressZipcode, kmmPayees.addressState AS addressState, kmmPayees.telephone AS telephone, kmmPayees.notes AS notes, kmmPayees.defaultAccountId AS defaultAccountId, kmmPayees.matchData AS matchData, kmmPayees.matchIgnoreCase AS matchIgnoreCase, kmmPayees.matchKeys AS matchKeys, kmmPayeesPayeeIdentifier.identifierId AS identId, kmmPayees.idPattern AS idPattern, kmmPayees.urlTemplate AS urlTemplate FROM ( SELECT * FROM kmmPayees ) kmmPayees LEFT OUTER JOIN kmmPayeesPayeeIdentifier ON kmmPayees.Id = kmmPayeesPayeeIdentifier.payeeId ORDER BY kmmPayees.id, kmmPayeesPayeeIdentifier.userOrder; Query error No 1054: Unknown column 'kmmPayees.idPattern' in 'field list' QMYSQL: Unable to execute query Error type 2 /var/tmp/portage/app-office/kmymoney-5.1.92_p20250306/work/kmymoney-17859b4f0b2a654c11e8e209fdc7ea097c7f4ea5/kmymoney/plugins/sql/mymoneystoragesql.cpp:1338 Dismissing the error window lead to a fresh (empty) KMyMoney; therefore I cannot access my accounting. I have contacted KDE (https://bugs.kde.org/show_bug.cgi?id=501591) and they mentioned that this new version is looking for a recently added field on a table in the DB that is missing on my DB. They will investigate why this version doesn't detect that I have an older version of the dataset and update it, but in the meantime they suggest for you to downgrade the tree to 5.1.3 for stable (5.1.92 can be kept for ~amd64).
KDE commit 4c86b5b1 added (among other things) two columns to the kmmPayees table. However, the commit was only added to master branch, not 5.1, so any database saved with 5.1.3 cannot be opened with 5.1.92 (or any version from master) without some new, explicit code to add the columns to any existing database. Would it be appropriate to revive the 5.1.3 ebuild, and consider marking 5.1.92 as testing?
That can only be a short-term solution, considering the Qt5Webengine dependency. Would that also necessitate a app-office/libalkimia-8.1.2 downgrade (from 8.1.92_p20250211)? I was wondering, anyway, why a tag was made from git master while that feels like being in full swing of development still, not branching off 5.2.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=20820a99313c76f93b6f4a0015bc758ed233e90f commit 20820a99313c76f93b6f4a0015bc758ed233e90f Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2025-03-17 00:22:19 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2025-03-17 00:22:19 +0000 profiles: Mask >=app-office/kmymoney-5.1.92 for DB migration issue Bug: https://bugs.gentoo.org/951486 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> profiles/package.mask | 4 ++++ 1 file changed, 4 insertions(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4d08a8dbdcb4ab37511b5e53f793844038832f08 commit 4d08a8dbdcb4ab37511b5e53f793844038832f08 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2025-03-16 23:28:21 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2025-03-16 23:33:47 +0000 app-office/kmymoney: Re-add 5.1.3 Bug: https://bugs.gentoo.org/951486 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> app-office/kmymoney/Manifest | 1 + .../kmymoney/files/kmymoney-5.1.3-cmake.patch | 28 +++++ app-office/kmymoney/kmymoney-5.1.3.ebuild | 131 +++++++++++++++++++++ 3 files changed, 160 insertions(+)
Asturm: note that the migration issue only applies to the SQL back end, as far as I know, and not to the XML back end, although I suppose that doesn't change anything. I'm not sure the versions released from master really need to be masked, as opposed to just marked testing, since the interim "fix" is to revert to 5.1.3, save as XML, upgrade, then re-save as SQL. Also, an MR has been filed for KMM to check whether it needs to alter the SQL database. My understanding of the logic of numbering is that current development is still aimed at releasing 5.2, and that 5.1.9x are essentially pre-release candidates. I don't believe there is anything in master which will not be included in 5.2, which will be branched when 5.2 is released. At that point, primary development effort will be directed to completing the port to Qt6/KDE6.
The package.mask gives users an explanation for the downgrade, which is why it is always prefered in such situations. I'll happily package a fixed snapshot after the MR got merged and restart stabilisation.
This issue exclusively impacts users who have selected database storage for their data. For those utilizing the .kmy file storage option, the application functions as expected. I had to mask 5.1.3 to prevent the downgrade and the build of the dependency dev-qt/qtwebengine-5 which will take merge time of approximately 7 hours.
(In reply to email200202 from comment #6) > This issue exclusively impacts users who have selected database storage for > their data. For those utilizing the .kmy file storage option, the > application functions as expected. > > I had to mask 5.1.3 to prevent the downgrade and the build of the dependency > dev-qt/qtwebengine-5 which will take merge time of approximately 7 hours. That's for letting us know that you can work with package.unmask.
(In reply to email200202 from comment #6) > This issue exclusively impacts users who have selected database storage for > their data. For those utilizing the .kmy file storage option, the > application functions as expected. ... and? There is no way that it's acceptable for us to play fast and loose with possible data loss. Nobody is going to thank us for being careless with that. Sometimes trade-offs like this happen.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9d1bd3442edac2a80a294cab4f7d283893425f20 commit 9d1bd3442edac2a80a294cab4f7d283893425f20 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2025-03-20 21:34:24 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2025-03-20 21:36:02 +0000 app-office/kmymoney: add 5.1.92_p20250320 Bug: https://bugs.gentoo.org/951486 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> app-office/kmymoney/Manifest | 1 + .../kmymoney/kmymoney-5.1.92_p20250320.ebuild | 122 +++++++++++++++++++++ profiles/package.mask | 2 +- 3 files changed, 124 insertions(+), 1 deletion(-)
Marco, if you can, and after you made a backup of your kmymoney Db, please try again with this newly added version.
(In reply to Andreas Sturmlechner from comment #10) > Marco, if you can, and after you made a backup of your kmymoney Db, please > try again with this newly added version. I upgraded and I am not getting the error any longer; I could also modify the data without any issue. The program keep freezing upon saving, but I think it is another unrelated issue: I am not at home, so I have to access the database via VPN; in the past (when I was at home) I was getting some occasional temporary freeze (~15-30 sec.) upon saving, so maybe it is a connection issue (even if at home I have a 10 Gbps and where I am I have ~100 Mbps). I am downgrading to 5.1.3 to check if it is the case (and therefore not related to this thread's issue). I will keep you informed as soon as I am done (qtwebengine-5 emerging at the moment).
(In reply to Marco Di Fresco from comment #11) > (In reply to Andreas Sturmlechner from comment #10) > > Marco, if you can, and after you made a backup of your kmymoney Db, please > > try again with this newly added version. > > I upgraded and I am not getting the error any longer; I could also modify > the data without any issue. > > The program keep freezing upon saving, but I think it is another unrelated > issue: I am not at home, so I have to access the database via VPN; in the > past (when I was at home) I was getting some occasional temporary freeze > (~15-30 sec.) upon saving, so maybe it is a connection issue (even if at > home I have a 10 Gbps and where I am I have ~100 Mbps). I am downgrading to > 5.1.3 to check if it is the case (and therefore not related to this thread's > issue). I will keep you informed as soon as I am done (qtwebengine-5 > emerging at the moment). The saving issue is present in 5.1.3 too, so it is unrelated. As far I can see, my original bug is fixed. Thank you very much.
You can take the saving issue up on one of the KMyMoney support channels, but remember that even though you are using the sql back end, it re-writes the entire database when you save, not just the new or changed data. It may be worth looking for a database related speed test to check your connection.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5bd9f863a9644be88eabd570b0d8dc8f248f42a3 commit 5bd9f863a9644be88eabd570b0d8dc8f248f42a3 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2025-03-25 14:43:48 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2025-03-25 14:44:08 +0000 app-office/kmymoney: add 5.1.92_p20250324 Upstream commit d18712f2a1be425eedbfca1c1f12bae5d9883755 KDE-bug: https://bugs.kde.org/show_bug.cgi?id=501686 Bug: https://bugs.gentoo.org/947737 Bug: https://bugs.gentoo.org/951486 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> app-office/kmymoney/Manifest | 1 + .../kmymoney/kmymoney-5.1.92_p20250324.ebuild | 122 +++++++++++++++++++++ 2 files changed, 123 insertions(+)
