[kmymoney] [Bug 473309] New: USD - GBP Exchange Rate Lookup Failing
https://bugs.kde.org/show_bug.cgi?id=473309 Bug ID: 473309 Summary: USD - GBP Exchange Rate Lookup Failing Classification: Applications Product: kmymoney Version: 5.1.3 Platform: Slackware OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kmymoney-devel@kde.org Reporter: david.houl...@gmail.com Target Milestone: --- When trying to update the exchange rate for USD->GBP or GBP->USD it has started failing. STEPS TO REPRODUCE 1. Select "Update Stock and Currency Prices. 2. Ensure there are entries for USD->GBP or GBP->USD. 3. Select those entries and click Update Selected. OBSERVED RESULT Message pops up "Failed to retrieve an exchange rate for USD > GBP from KMyMoney Currency. It will be skipped this time." In the status window these messages are output. Fetching URL https://fx-rate.net/GBP/USD... Identifier found: '' Price found: '1.2694' (1.2694) Unable to update price for GBP > USD (no price or no date) Fetching URL https://fx-rate.net/USD/GBP... Identifier found: '' Price found: '0.78777' (0.78777) Unable to update price for USD > GBP (no price or no date) EXPECTED RESULT Exchange rate should be updated SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 473128] Fetching currency conversions from fx-rate.net is broken
https://bugs.kde.org/show_bug.cgi?id=473128 david.houl...@gmail.com changed: What|Removed |Added CC||david.houl...@gmail.com --- Comment #2 from david.houl...@gmail.com --- *** Bug 473309 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 473309] USD - GBP Exchange Rate Lookup Failing
https://bugs.kde.org/show_bug.cgi?id=473309 david.houl...@gmail.com changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from david.houl...@gmail.com --- Apologies. Found a duplicate of this bug. *** This bug has been marked as a duplicate of bug 473128 *** -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 473308] Kmymoney does not open the file anymore
https://bugs.kde.org/show_bug.cgi?id=473308 Jack changed: What|Removed |Added CC||ostroffjh@users.sourceforge ||.net --- Comment #1 from Jack --- Please give a little history. (I don't know if it matters, but which version of Zorin are you using?) Are you saying that you have previously opened this same file with the same 5.0.0 that you are now using? If that is the case, then perhaps the file has been damaged. Do you have any backups? Have you just upgraded from a prior version (either of Zorin or of KMM?) If so, what version? For it to have not actually upgraded from that old data format, but actually read it seems unlikely unless it was an extremely old version. Note that the currently released version of KMM is 5.1.3, so 5.0.0 is considered extremely old, and no longer directly supported, other than helping you get your data successfully open in a recent version. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 473223] Data lost on kmymoney-master-2001-macos-clang-x86_64.dmg upgrade
https://bugs.kde.org/show_bug.cgi?id=473223
--- Comment #17 from Neil ---
Thanks to all of you for your efforts - I began looking at the xml code, which
led me to think that problem might be my sloppy handling of securities as there
were 74 instances of currency="E**". At which point I thought to look how
the version upgrade handled a much smaller .kmy file (216kB) with no
securities.
This Linux .kmy has 4519 transactions with 9174 splits. Upon opening it from
5.1.80 the currency window came up. Upon choosing USD and closing the window
the Home Screen displayed the status of the accounts at the end of 2017.
File Information shows 173 transactions and 345 splits. Upon saving the file
size became 25kB. Transactions later than 2017 were lost. The console printout
did not indicate errors.
Printed Log Upon opening:
2023-08-12 14:41:42.746 kmymoney[8482:577400] +[CATransaction synchronize]
called within transaction
Open file
QUrl("file:///Users/neilralph/Downloads/kmymoney/RalphCenterportGood.kmy")
Model for "I" loaded with 7 items in 0 ms
Model for "P" loaded with 1030 items in 5 ms
Start verifying account hierarchy
End verifying account hierarchy
Model for accounts loaded with 179 items in 1 ms
Model for "T" loaded with 345 items in 0 ms
Printed Log Upon closing Currency Dialog:
Start calculating balances: 345 splits
End calculating balances
Processed home view section 8 in 1 ms
Processed home view section 1 in 0 ms
Processed home view section 2 in 0 ms
Processed home view section 3 in 1 ms
Processed home view section 4 in 0 ms
Processed home view section 5 in 2 ms
Processed home view section 6 in 58 ms
Processed home view section 7 in 0 ms
Processed home view section 10 in 0 ms
Plugins: budgetview unloaded
Plugins: checkprinting unloaded
Plugins: csvexporter unloaded
Plugins: csvimporter unloaded
Plugins: forecastview unloaded
Plugins: gncimporter unloaded
Plugins: icalendarexporter unloaded
Plugins: kbanking unplugged
Plugins: kbanking unloaded
Plugins: ofximporter unloaded
Plugins: onlinejoboutboxview unloaded
Plugins: qifexporter unloaded
Plugins: qifimporter unloaded
Plugins: reconciliation report unloaded
Plugins: reportsview unloaded
Plugins: sqlstorage unloaded
Plugins: xmlstorage unloaded
--
You are receiving this mail because:
You are the assignee for the bug.
[kmymoney] [Bug 473223] Data lost on kmymoney-master-2001-macos-clang-x86_64.dmg upgrade
https://bugs.kde.org/show_bug.cgi?id=473223 --- Comment #18 from Jack --- What might an example of "sloppy handling of securities?" Assuming you have not edited the kmy file manuallly (after uncompressing into xml) then the program should only ever delete a security if there is no remaining reference to it left in the file. Also, if the new version also truncated a file with no securities, then there is (also) something else going on. It would be nice if we could figure out why it is opening the currency dialog when opening the file. Have you been able to try xmllint (or equivalent) against any of these xml files? Can you grep for CURRENCY in the files? Also, if all these cases are with data files you have transferred from Linux to MacOS, can you try transferring one of them back to Linux and compare it to the original? -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 473322] New: SLQLite "kmmSplits"."sharesFormatted" Data Corrupt perhaps??
https://bugs.kde.org/show_bug.cgi?id=473322 Bug ID: 473322 Summary: SLQLite "kmmSplits"."sharesFormatted" Data Corrupt perhaps?? Classification: Applications Product: kmymoney Version: 5.1.3 Platform: openSUSE OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: database Assignee: kmymoney-devel@kde.org Reporter: vanques...@gmail.com Target Milestone: --- After problems with base currency conversions in reports, I've been running parameterized, preprepared SQL queries from the BASH command line very successfully but they require parsing the fractional value of "kmmSplits"."sharesFormatted" each time the quantity of shares is required. It seems that formatting commas etc have been removed from the comparable "kmmSplits"."valueFormatted" field so it can be used without parsing but "kmmSplits"."sharesFormatted" bears no relation to the quantity of shares at all (seems to be an integer rounding of the "kmmSplits"."priceFormatted" field). It would make life much easier if "kmmSplits"."sharesFormatted" held the decimal value of "kmmSplits"."shares" (albeit as TEXT). Apologies if "kmmSplits"."sharesFormatted" is being used for some other purpose and this is not a bug at all. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 473322] SLQLite "kmmSplits"."sharesFormatted" Data Corrupt perhaps??
https://bugs.kde.org/show_bug.cgi?id=473322 --- Comment #1 from Jack --- Ouch. You are right, sharesFormatted does appear to be the price, formatted to a precision dependent on the account of the split. I'll have to dig into the code to see what's going on. -- You are receiving this mail because: You are the assignee for the bug.
How to deal with clang-format
I'm finding git requiring me to run clang-format on most code changes. Most of the time, it is fine - just fixing up bad indentation (tabs -> spaces) but sometimes it completely re-indents something in ways that make it actually harder to read, or using longer lines. https://community.kde.org/Policies/Frameworks_Coding_Style says you can use a comment at the end of a line to preserve manual line breaks, but I have a case where it still re-flows, putting ". //" on a line by itself. Do we have a preference on how to handle this, or do we just let clang-format do its thing? Related - is there a way to get emacs to use the required formatting style without having to explicitly run clang-format (either in emacs or command line) ? Jack
How to deal with clang-format
I'm finding git requiring me to run clang-format on most code changes. Most of the time, it is fine - just fixing up bad indentation (tabs -> spaces) but sometimes it completely re-indents something in ways that make it actually harder to read, or using longer lines. https://community.kde.org/Policies/Frameworks_Coding_Style says you can use a comment at the end of a line to preserve manual line breaks, but I have a case where it still re-flows, putting ". //" on a line by itself. Do we have a preference on how to handle this, or do we just let clang-format do its thing? Related - is there a way to get emacs to use the required formatting style without having to explicitly run clang-format (either in emacs or command line) ? Jack
[kmymoney] [Bug 473223] Data lost on kmymoney-master-2001-macos-clang-x86_64.dmg upgrade
https://bugs.kde.org/show_bug.cgi?id=473223 --- Comment #19 from Thomas Baumgart --- Your "Users/neilralph/Downloads/kmymoney/RalphCenterportGood.kmy" file is a good example. You mention it shows 4519 on your Linux machine but loads only the first 345 on MacOS. So it seems that either transaction 345 or 346 in the list may contain the culprit. I shoot for the latter. Here's how we can easily find out on which line that is in the XML file (assuming you have converted that file to XML format already): grep -n '
