Why did you change the title to database, if you are opening a .kmy file?  
Please see if this might be the same issue as https://bugs.kde.org/show_bug.cgi?id=507404.

This is a duplicate of bug #507404. Please see the instructions how to circumvent the crash temporarily.

*** This bug has been marked as a duplicate of bug 507404 ***

Reopening based upon some side discussions with Thomas indicating this bug is not a duplicate in retrospect.

I pulled down the current state of the repo (hash 1fa0eef43b997ca207ce5a916397ef3def528545), incidentally, the build-deps currently are missing libkf5crash-dev for building, but I was able to rebuild without issue.

Interestingly, whatever changes occurred in the last couple of weeks, or using the default build flags is preventing the crash on startup, but only "recent-ish" accounts are visible in the summary view. Navigating to the "accounts" view shows the accounts and I can open them in the "ledgers" view without issue. Resizing the window while the "home" view is visible spits out numerous warnings/errors about unknown account IDs. An example follows of a pair tied to a specific transaction. 

> MyMoneyFile::countTransactionsWithSpecificReconciliationState: unknown account id "3-account" in transaction "T000000000000002664"
> MyMoneyFile::countTransactionsWithSpecificReconciliationState: unknown account id "66-category" in transaction "T000000000000002664"

From what I can gather, the problem is tied to data that came from an import I did years ago from Skrooge to Kmymoney (the missing accounts are all accounts I opened/made prior to migrating from Skrooge to Kmymoney), and those legacy transactions having strange metadata. For example, the following is the contents of the specific transaction referenced above. Clearly the accounts should not be a mix of an account and a category. 

   <TRANSACTION entrydate="2016-10-30" id="T000000000000002664" postdate="2016-10-30" memo="" commodity="USD">
   <SPLITS>
    <SPLIT reconcileflag="2" payee="P000237" shares="-897/100" price="1/1" action="" id="S0001" reconciledate="" memo="" bankid="" number="" account="3-account" value="-897/100"/>
    <SPLIT reconcileflag="1" payee="P000237" shares="897/100" price="1/1" action="" id="S0002" reconciledate="" memo="" bankid="" number="" account="66-category" value="897/100"/>
   </SPLITS>
  </TRANSACTION>

I think the bug is likely caused by all of these legacy transactions that are internally stored as a split. I've confirmed the accounts being complained about are all correctly in the XML, as are the categories incorrectly placed into the account field. The malformed splits are so old that Kmymoney isn't showing them in the ledgers. There are some entries that are recent, but only produce one complaint/warning in the console. Inspecting those indicates they're likely representing a transfer between a modern and imported account, and the warning is about the legacy account.

This might simply be Kmymoney having changed some bit of logic tied to the structure of account IDs and categories in a way that was not historically a problem, and imported accounts violating these assumptions.

A few points:
- KMyMoney treats Categories internally a special type of Account, so that is not the problem.  Most transactions have two splits - one for the account the money is coming from, and the other split for the Category the money is going to.
- if that commit is from master or 5.2 branch, then at this point, it should be built against Qt6/KF6, but missing libkf5crash-dev seems to indicate you are still building against Qt5/KF5.  While I think that is still theoretically possible, I believe that not all fixes and enhancements that are specific to the Qt6 code have been backported to the Qt5 code, and will likely not be, so it is important to be sure your errors do still show up with a Qt6 build.
- internal references to Accounts should all be Annnnnn, the actual internal id of the account.  The use of the old Skrooge account names in the id field is clearly part of the problem, but it sounds like it has been that way for a while without causing problems.  Do you have a backup of your data file from before the problem started?  If so, it would be interesting to see how 5.1.3 handles them and if you can see those accounts in the ledger.
- What does a consistency check show?

(In reply to Jack from comment #4)
> - if that commit is from master or 5.2 branch, then at this point, it should
> be built against Qt6/KF6, but missing libkf5crash-dev seems to indicate you
> are still building against Qt5/KF5.  While I think that is still
> theoretically possible, I believe that not all fixes and enhancements that
> are specific to the Qt6 code have been backported to the Qt5 code, and will
> likely not be, so it is important to be sure your errors do still show up
> with a Qt6 build.

Ah. Probably worth an update to the build instructions, but this could be user error. Either way it seems to be unrelated to this bug.

> - internal references to Accounts should all be Annnnnn, the actual internal
> id of the account.  The use of the old Skrooge account names in the id field
> is clearly part of the problem, but it sounds like it has been that way for
> a while without causing problems.  Do you have a backup of your data file
> from before the problem started?  If so, it would be interesting to see how
> 5.1.3 handles them and if you can see those accounts in the ledger.

5.1.3 continues to work without issue. Something has changed since that release.

> - What does a consistency check show?

Consistency check indicates no problems.
> The consistency check has found no issues in your data. Details are presented below.
> Finished: data is consistent.

That something has changed since 5.1.3 is a bit of an understatement :-)  I assume you ran the consistency check under 5.1.3, if 5.2 crashes for you.  I suspect the 5.2 consistency check might find some issues.  I don't want to duplicate any of the troubleshooting you have done with Thomas, but have you run the program under a debugger to get a backtrace?
Can you extract the <ACCOUNT ......> entry for one of those imported accounts, perhaps one regular account and one category?  I'm curious whether there is a problem with how the accounts/categories themselves were imported, or if it is only with how the imported transactions refer to them.

A few clarifications of statements that have been made in this thread. Some more instructions on how to proceed at the end of this message.

> While I think that is still theoretically possible, I believe that not all fixes and
> enhancements that are specific to the Qt6 code have been backported to the
> Qt5 code, and will likely not be, so it is important to be sure your errors do
> still show up with a Qt6 build.
At this point in time, the code base supports all features on Qt5 and has a few quirks on Qt6 (due to missing/broken support of some stuff we had in Qt5 e.g. bug #507049) which renders the above statement as false.

> the categories incorrectly placed into the account field
Category is a synonym for income/expense account. So if category ids show up in accountId fields that is perfectly fine and happens by design.

> Interestingly, whatever changes occurred in the last couple of weeks,
> or using the default build flags is preventing the crash on startup
It is these two changes (https://invent.kde.org/office/kmymoney/-/commit/cb50551c and https://invent.kde.org/office/kmymoney/-/commit/7c5ac5cc) which prevent the crash and removes the offending split and shows the transaction as unassigned.

> ... but have you run the program under a debugger to get a backtrace?
No need, since we caught the culprit with some debug output and fixed it in https://invent.kde.org/office/kmymoney/-/commit/7c5ac5cc

> This might simply be Kmymoney having changed some bit of logic tied
> to the structure of account IDs and categories in a way that was not
> historically a problem, and imported accounts violating these assumptions.
If that is the case it did not happen deliberately. Nevertheless, the code to organize the data in memory has been completely rewritten between 5.1.3 and 5.2 but it could well be that the new code assumes the first character of an account/category id to be the character A when looking for accounts/categories which is not true in all of your cases.

Next step: KMyMoney supports a feature to create an anonymized version of your data which allows the developers to look at the structure without disclosing private information. Please see https://docs.kde.org/stable5/en/kmymoney/kmymoney/details.formats.anonymous.html on how to create one. Since they are XML you can take a look for yourself. Please send them to me directly, no need for the mailing list mentioned or attaching it to this ticket.

Please create one version of the anon file using 5.1.3 with the original data from your backup (i.e. unaltered by 5.2) and one created with the version of 5.2 you built yourself. Make sure that the version created with 5.1.3 still shows the symptoms when loaded using 5.2.

🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!

(In reply to Thomas Baumgart from comment #7)
> Next step: KMyMoney supports a feature to create an anonymized version of
> your data which allows the developers to look at the structure without
> disclosing private information. Please see
> https://docs.kde.org/stable5/en/kmymoney/kmymoney/details.formats.anonymous.
> html on how to create one. Since they are XML you can take a look for
> yourself. Please send them to me directly, no need for the mailing list
> mentioned or attaching it to this ticket.
> 
> Please create one version of the anon file using 5.1.3 with the original
> data from your backup (i.e. unaltered by 5.2) and one created with the
> version of 5.2 you built yourself. Make sure that the version created with
> 5.1.3 still shows the symptoms when loaded using 5.2.

A couple of bugs at play here. The first of which is when saving as an .anon.xml file in 5.1.3, Kmymoney just produces a regular .kmy file. Gunziping it manually reveals the full non-anonymized data. The feature works as expected in the current git head, but the <institutions> section simply omits accounts that were imported and have offending IDs. I'll send the 5.2 export your way, but I suspect the A/B comparison will be difficult. I will note that the files have roughly the same amount of lines, which suggests the bit of logic causing the snag is specifically in the section of the code base parsing institutions or accounts specifically.

> A couple of bugs at play here. The first of which is when saving as an .anon.xml
> file in 5.1.3, Kmymoney just produces a regular .kmy file.
I just tried that being careful to select the file type in the combo box to be .anon.xml and it saved such a file using a KMyMoney 5.1.3-eef04f1 (dated Fri May 3 18:30:48 2024). I provided a name without any dots. Maybe, you can try creating the anon file with 5.1.3 again. 

The file you sent indeed misses some account records but has references to it, both from other accounts as well as transactions (e.g. "239-category").

Git commit 1ef8bc926b93f2e4fbe73319f3d4a49c79d11629 by Thomas Baumgart.
Committed on 24/08/2025 at 09:58.
Pushed by tbaumgart into branch 'master'.

Use correct method to determine top level parent id

In case an account referenced an unknown parent account duing loading,
it needs to be reparented to the corresponding top level account group.
The logic to determine that top level account group did not work as
expected so that an empty account id was used, which caused problems
(crashes) later on. This change now uses the new method to get the right
parent id.

M  +11   -7    kmymoney/mymoney/storage/accountsmodel.cpp

https://invent.kde.org/office/kmymoney/-/commit/1ef8bc926b93f2e4fbe73319f3d4a49c79d11629

Git commit 0d0783479b0375c243aff7126ddfd210476a632c by Thomas Baumgart.
Committed on 24/08/2025 at 10:24.
Pushed by tbaumgart into branch '5.2'.

Use correct method to determine top level parent id

In case an account referenced an unknown parent account duing loading,
it needs to be reparented to the corresponding top level account group.
The logic to determine that top level account group did not work as
expected so that an empty account id was used, which caused problems
(crashes) later on. This change now uses the new method to get the right
parent id.
(cherry picked from commit 1ef8bc926b93f2e4fbe73319f3d4a49c79d11629)

M  +11   -7    kmymoney/mymoney/storage/accountsmodel.cpp

https://invent.kde.org/office/kmymoney/-/commit/0d0783479b0375c243aff7126ddfd210476a632c

(In reply to Thomas Baumgart from comment #12)
> Git commit 0d0783479b0375c243aff7126ddfd210476a632c by Thomas Baumgart.
> Committed on 24/08/2025 at 10:24.
> Pushed by tbaumgart into branch '5.2'.
> 
> Use correct method to determine top level parent id
> 
> In case an account referenced an unknown parent account duing loading,
> it needs to be reparented to the corresponding top level account group.
> The logic to determine that top level account group did not work as
> expected so that an empty account id was used, which caused problems
> (crashes) later on. This change now uses the new method to get the right
> parent id.
> (cherry picked from commit 1ef8bc926b93f2e4fbe73319f3d4a49c79d11629)
> 
> M  +11   -7    kmymoney/mymoney/storage/accountsmodel.cpp
> 
> https://invent.kde.org/office/kmymoney/-/commit/
> 0d0783479b0375c243aff7126ddfd210476a632c

The solution you provided via email relative to the extrusions/corrupted categories in the history of the file do appear to fix the crash, and it does let me open both the real file and the anonymous file without crashing, but all of the accounts that are under institution I used prior to migrating to kmymoney are not visible in the app. I'm happy to open a distinct bug, but I think all of these are tied to the same root cause of lack of a strong way to normalize IDs and names from imported files.

In this case all of the institution have IDs and names that are of the form "#-bank" where # is a number.
A global find and replace in my XML file that converted  #-bank to "I10000#", a similar replace for #-account, and #-category into unique account IDs appears to restore the file relative to the master appimage build, but I suspect the real trick here is to either make the logic behind the well-formed-ness of "ID" fields more agnostic to the exact form these might have taken in the past, and provide a mechanism to re-normalize them for the future.