Created attachment 117793 [details] Screenshot of error message SUMMARY I spent some time tidying-up my Categories (re-arranging hierarchies; deleting some; etc.). When I attempted to save changes, the program crashed, and with each attempt to re-start, I get the error message shown in the attached screenshot. Please let me know how I can fix this! STEPS TO REPRODUCE 1. Attempt to launch KMyMonet as usual by clicking on the launcher icon. 2. Error message appears: "Uncaught error. Please report the details to the developers" 3. Click the "Detail>>" button, and I get a more detailed error message OBSERVED RESULT See attachment. EXPECTED RESULT Program starts as normal SOFTWARE/OS VERSIONS Windows: MacOS: Linux/KDE Plasma: Ubuntu 18.04.1 LTS (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Ouch. This should not have happened, but it did. Problem is that some object inside your data file still has a link to a category/account that you deleted. This one is not found anymore now but needed. We need to figure out what is causing the problem and correcting it. As a first step make a copy of your data file and keep it in a safe place. Then run the following command in a terminal window (I will use <<file>> as a placeholder for your data file in the following including the .kmy extension): zgrep A000083 <<file>> The next steps are hard to predict at this point. It depends on what you get from the above command. In case it is short (a few lines), please drop it here for us to analzye. Feel free to replace any alphanumeric character which represents personal information with the letter X but do not change the format of the data otherwise. Leave IDs as they are. In case it is long (many lines), try to figure out what this account/category could have been and report back here and we will proved the next instructions.
Created attachment 117834 [details] output from zgrep
That's very strange. zgrep knows the file is compressed, uncompresses it, and passes it to grep. I don't know how, but it looks like your file might be double compressed. Can you try "file peter.kmy" to see what it says? You might then also try (as sequential commands) "cp peter.kmy x.gz" "gunzip x.gz" "file x". that x SHOULD be a plain ascii xml file. If file says it is gzip compressed, then you can try "zgrep A000083 x" and we can go from there.
Indeed strange, I just tried it here and it worked as expected. I doubt the double compression, though. In that case, KMyMoney would not be able to read the file and provide an error message with an account id. Using the 'file' tool is the way to go. For a regular kmy file it should say something like this: thb@thb-nb:~$ file tus.kmy tus.kmy: gzip compressed data, was "", last modified: Tue Feb 5 08:17:06 2019, from Unix If you get such an output, then you could also try the following zcat peter.kmy | grep A000083 which is basically what zgrep should do/should have done. In other cases, knowing the output of the file command would be helpful.
Created attachment 117838 [details] Output from "file" and "zcat" commands The attachment should be self explanatory. If you are interested to find the cause of this problem, I am willing to keep trying things, but you do not need to spend more time on this on my behalf, as I have successfully restored a recent backup of peter.kmy
Certainly, we are interested. What is the output of zcat peter.kmy | od -Ax -t cz | head -n 15 which should show us the beginning of the file in detail.
Created attachment 117840 [details] Output of zcat peter.kmy | od -Ax -t cz | head -n 15
This looks ok, no binary garbage in the beginning. Next commands: zcat peter.kmy > peter.xml xmllint --noout peter.xml The above might not produce any output (which is OK). If it does, please report it. In any case you can use your favorite editor to take a look at peter.xml and search for the A000083. How many times do you find it? Which is the XML element it is contained in?
Created attachment 117841 [details] output of "xmllint --noout peter.xml" When I open the xml file with a text editor, I find that "A000083" occurs 18 times. This is the context of the first occurrence: <ACCOUNT lastmodified="2014-07-30" institution="" opened="1900-01-01" currency="GBP" id="A000082" parentaccount="AStd::Income" lastreconciled="" description="" number="" type="12" name="Pay"> <SUBACCOUNTS> <SUBACCOUNT id="A000083"/> <SUBACCOUNT id="A000108"/> <SUBACCOUNT id="A000161"/> <SUBACCOUNT id="A000163"/> </SUBACCOUNTS> Comparing the subsequent occurrences with my backed-up version of the .kmy file, it seems that they all refer to deposits into my current account, where there are two "<SPLIT action="s e.g.: <TRANSACTION id="T000000000000000546" entrydate="2010-12-31" postdate="2009-01-21" memo="SFRB01" commodity="GBP"> <SPLITS> <SPLIT action="" id="S0001" value="400/1" payee="P000197" reconciledate="" number="" shares="400/1" account="A000060" bankid="2009-01-21-4fbeb77-1" reconcileflag="2" memo="SFRB01"/> <SPLIT action="" id="S0002" value="-400/1" payee="" reconciledate="" number="" shares="-400/1" account="A000083" bankid="" reconcileflag="2" memo="SFRB01"/> </SPLITS> </TRANSACTION> and <TRANSACTION id="T000000000000000559" entrydate="2010-12-31" postdate="2009-01-30" memo="" commodity="GBP"> <SPLITS> <SPLIT action="" id="S0001" value="836/1" payee="P000198" reconciledate="" number="" shares="836/1" account="A000060" bankid="2009-01-30-3846fc7-1" reconcileflag="2" memo=""/> <SPLIT action="" id="S0002" value="-836/1" payee="" reconciledate="" number="" shares="-836/1" account="A000083" bankid="" reconcileflag="2" memo=""/> </SPLITS> </TRANSACTION>
If A000083 is still in your backup then you know what it is/was. It seems to be some income category and a sub-account of 'Pay' (A000082). If it does not have any sub-accounts then it might be easy to move that XML-section over from the backup. Drop it right behind the A000082 entry. Your mileage may vary, though. I wonder though, how you could delete the category since it was still referenced by transactions.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!