I saved my encrypted file to XML so grepping did work.
Every version, including 5.2, worked until the last 2 or 3 weeks so
maybe this problem occurred 15 years ago when KMM allowed something to
be deleted that it shouldn't have, but KMM did not have a problem with
the file until this recent change.
I'd fix it if I could but I have no idea what is missing so I unless KMM
lets me know what is missing it's doesn't really matter if I can load it
but not save it.
When I go to Investments / Equities in that account with the problem
there is nothing there. I can't edit any of the transactions in the
investment account so I'm not sure how I would add what is missing.
I'll keep poking around.
**
*Brendan Coupe*
*3...@coupe7.com*
On 2025-09-09 4:12 PM, Jack via KMyMoney-devel wrote:
A .kmy file is gzipped, so grep wont work - you need to use zgrep or
gunzip the file first.
I've had a similar thought about the wording of that message. However,
I'm not sure it is related to your underlying problem, as a closed
security account still exists, so it is valid for a transaction to
refer to it. However, if the Category is what has been deleted, then
yes, for now you will need to reopen the security account before
editing the transaction.
One issue now is that 5.1.3 does not check for the issue, so it will
save your data in a form that will fail to load in any later version
which does check for that issue. I don't know it it is reasonable to
allow loading such a file, but just not saving it. Perhaps allow
loading it but not doing anything except fixing the problem (reassign
the Category before saving.) That will require further discussion,
but as you are the second person to report the issue, we really should
find a better solution than grepping the saved file and then editing
the transactions one at a time.
On 9/9/25 6:03 PM, Brendan Coupe via KMyMoney-devel wrote:
Thanks. The transactions are from 2009. The investment account they
are in is closed. When I reopen it and try to open any of the
investments in the account I get:
KMyMoney does not support to edit transaction that reference closed
accounts. This could be worded better:
How about "KMyMoney does not support editing transactions that
reference closed accounts."
I have no idea how to fix this.
grep A000432 MyMoney.kmy | grep '<ACCOUNT>'
returns nothing.
grep A000432 MyMoney.kmy | wc
returns 9 lines but there are many more investments in the brokerage
account than 9. It appears that every equity and CD in that account
returns the same error.
This is frustrating since I have 20 years of data that I can no
longer access. It passes the consistency check with the August
version. It seems like it should have failed the consistency check
with some guidance on how to fix it before KMM refused to open the file.
**
*Brendan Coupe*
*3...@coupe7.com*
On 2025-09-09 12:24 PM, Jack via KMyMoney-devel wrote:
On 9/9/25 2:21 PM, Jack via KMyMoney-devel wrote:
On 9/9/25 2:08 PM, Brendan Coupe via KMyMoney-devel wrote:
When I compile either the 5.2 or the master branch I get the
following error when trying to open my file:
Corrupted data: transaction '', split 'S0002' references unknown
account id 'A000432'
/usr/local/src/kmm/kmymoney-2025.09.09-11.47.31-GIT-MASTER/kmymoney/plugins/xml/mymoneyxmlreader.cpp:771
Since my file is encrypted, the first thing I tried was decrypting
the file. I got the same error. When I switch back to the version
I compiled on August 21, the file opens as expected. The first
time this happened was about a week ago but I didn't try
decrypting the file first until today.
Something in the past few weeks seems to have caused this problem.
I think this has been reported by someone else recently, but can't
currently find the reference.
https://discuss.kde.org/t/kmm-5-2-1-cannot-open-file/39428
It seems to be due to a new check that has been added recently.
What you can do is grep for that account number in your data file
after decrypting and find what transaction contains that split.
Then open that transaction in an older working version and check if
the category is valid. If not, change it to a valid Category. You
may then find a different transaction with the same problem, so you
will need to repeat the process. Apparently at some point in the
past, it was possible to delete a Category without deleting or
reassigning all transations/splits which referred to it.
