GnuCash crash on secret payload in XML file
OK, it's late at night, and I did something that Trevor likes doing. :) I went looking for trouble. But hey, I had a good reason, and had been planning this experiment for weeks already. My current accounting is still my own FoxPro concoction (started in 1992 and updated a few hundred times), and for the last few years I knew I would have to move it. Besides export/import issues, I have several extra fields of information that I need to preserve (even if not accessible outside of raw XML editing), so I edited a good GnuCash native XML file by adding a secret payload in one existing transaction with <mynewtag>mypayload</mynewtag>, at the same level as the other fields of that transaction. I was hoping it would be ignored on load, and restored on save. The result: GnuCrash crashed totally while opening the edited XML file! Yeah, just crashed with a crash message and self-quit after that. Is GnuCash that unstable??? BTW, a simple raw XML edit of an existing text field of a transaction works fine, and is then shown in GnuCash when the file is opened. Hartmut W Sager - Tel +1-204-339-8331
On Monday, March 13, 2017 3:04:57 AM CDT Hartmut W Sager wrote:
so I edited a good GnuCash native XML file by adding a secret payload in one existing transaction with <mynewtag>mypayload</mynewtag>, at the same level as the other fields of that transaction.
I think you can put arbitrary key-value pairs in <trn:slots>. I tried a quick experiment, and <gnc:transaction version="2.0.0"> ... <trn:slots> <slot> <slot:key>mystuff</slot:key> <slot:value type="string">mything</slot:value> </slot> survived a load-edit-save cycle.
Oooh, thanks, this is valuable! I will experiment further with what you did. And I presume that this is within the specs or design intentions of GnuCash, so that it should remain usable in further GnuCash versions? Hartmut W Sager - Tel +1-204-339-8331 On 13 March 2017 at 17:53, Glen Ditchfield <GJDitchfield@acm.org> wrote:
On Monday, March 13, 2017 3:04:57 AM CDT Hartmut W Sager wrote:
so I edited a good GnuCash native XML file by adding a secret payload in one existing transaction with <mynewtag>mypayload</mynewtag>, at the same level as the other fields of that transaction.
I think you can put arbitrary key-value pairs in <trn:slots>. I tried a quick experiment, and <gnc:transaction version="2.0.0"> ... <trn:slots> <slot> <slot:key>mystuff</slot:key> <slot:value type="string">mything</slot:value> </slot> survived a load-edit-save cycle.
_______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
On Monday, March 13, 2017 6:27:53 PM CDT Hartmut W Sager wrote:
Oooh, thanks, this is valuable! I will experiment further with what you did. And I presume that this is within the specs or design intentions of GnuCash, so that it should remain usable in further GnuCash versions?
Usable compared to hand-rolled FoxPro? But, yeah, I'd go with it. "It's been the (unfortunate) practice through most of Gnucash 2's development to use KVP to add or extend new variables to Gnucash because doing so allows older versions of Gnucash to open the data file." (http://gnucash.1415818.n4.nabble.com/what-is-the-table-slots-good-for-td4658...) Keep in mind that GnuCash has database back-ends, too. I wouldn't trust the front end to handle anything unless all the back ends support it. There's some weak documentation at https://wiki.gnucash.org/wiki/GnuCash_XML_format and https://wiki.gnucash.org/wiki/SQL.
Usable compared to hand-rolled FoxPro?
I had to read that a few times to conclude that it's a (FoxPro) compliment. :) Thanks hugely for the further info and links. That "backward compatible extensions via KVP's" is a ridiculously compromised architecture, and has me seriously considering not pursuing GnuCash any further. Since GnuCash updates are always available for free (and include a boatload of bug fixes every time), there is not the slightest reason to maintain this backward compatibility, just forward compatibility (old file can be loaded into next newer GnuCash version, but not saved backward). I have also been considering several other "roll my own" options for the last few years, notably MySQL/MariaDB/PHP. Being a heavy-duty algorithmic programmer, I am very intolerant of inadequate software, and "roll my own" often becomes my best choice. If you're wondering why I have to leave FoxPro, it's because Microsoft is letting it disintegrate, despite it still being officially a currently supported product. In fact, as I rudely discovered a year ago, it wouldn't even install on Windows 10 without a special patch being run first. I.e., Microsoft didn't even test the installability (let alone proper operation) on Windows 10 of a currently supported product of their own! GnuCash is visually very well done, though, I must say! And it is quite feature-laden. Hartmut W Sager - Tel +1-204-339-8331 On 13 March 2017 at 19:03, Glen Ditchfield <GJDitchfield@acm.org> wrote:
On Monday, March 13, 2017 6:27:53 PM CDT Hartmut W Sager wrote:
Oooh, thanks, this is valuable! I will experiment further with what you did. And I presume that this is within the specs or design intentions of GnuCash, so that it should remain usable in further GnuCash versions?
Usable compared to hand-rolled FoxPro?
But, yeah, I'd go with it. "It's been the (unfortunate) practice through most of Gnucash 2's development to use KVP to add or extend new variables to Gnucash because doing so allows older versions of Gnucash to open the data file." (http://gnucash.1415818.n4.nabble.com/what-is-the-table- slots-good-for-td4658122.html)
Keep in mind that GnuCash has database back-ends, too. I wouldn't trust the front end to handle anything unless all the back ends support it. There's some weak documentation at https://wiki.gnucash.org/wiki/ GnuCash_XML_format and https://wiki.gnucash.org/wiki/SQL.
_______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
Oh, as for the database back-ends to GnuCash, note that this is still officially experimental, with no guarantee of data integrity (the GnuCash site says "data loss can occur"). Other than that, I concur with your comments re the database back-ends. Hartmut W Sager - Tel +1-204-339-8331 On 13 March 2017 at 21:47, Hartmut W Sager <hwsager@marityme.net> wrote:
Usable compared to hand-rolled FoxPro?
I had to read that a few times to conclude that it's a (FoxPro) compliment. :)
Thanks hugely for the further info and links. That "backward compatible extensions via KVP's" is a ridiculously compromised architecture, and has me seriously considering not pursuing GnuCash any further. Since GnuCash updates are always available for free (and include a boatload of bug fixes every time), there is not the slightest reason to maintain this backward compatibility, just forward compatibility (old file can be loaded into next newer GnuCash version, but not saved backward).
I have also been considering several other "roll my own" options for the last few years, notably MySQL/MariaDB/PHP. Being a heavy-duty algorithmic programmer, I am very intolerant of inadequate software, and "roll my own" often becomes my best choice.
If you're wondering why I have to leave FoxPro, it's because Microsoft is letting it disintegrate, despite it still being officially a currently supported product. In fact, as I rudely discovered a year ago, it wouldn't even install on Windows 10 without a special patch being run first. I.e., Microsoft didn't even test the installability (let alone proper operation) on Windows 10 of a currently supported product of their own!
GnuCash is visually very well done, though, I must say! And it is quite feature-laden.
Hartmut W Sager - Tel +1-204-339-8331 <%28204%29%20339-8331>
On 13 March 2017 at 19:03, Glen Ditchfield <GJDitchfield@acm.org> wrote:
On Monday, March 13, 2017 6:27:53 PM CDT Hartmut W Sager wrote:
Oooh, thanks, this is valuable! I will experiment further with what you did. And I presume that this is within the specs or design intentions of GnuCash, so that it should remain usable in further GnuCash versions?
Usable compared to hand-rolled FoxPro?
But, yeah, I'd go with it. "It's been the (unfortunate) practice through most of Gnucash 2's development to use KVP to add or extend new variables to Gnucash because doing so allows older versions of Gnucash to open the data file." (http://gnucash.1415818.n4.nabble.com/what-is-the-table-slot s-good-for-td4658122.html)
Keep in mind that GnuCash has database back-ends, too. I wouldn't trust the front end to handle anything unless all the back ends support it. There's some weak documentation at https://wiki.gnucash.org/wiki/ GnuCash_XML_format and https://wiki.gnucash.org/wiki/SQL.
_______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
On 2017-03-13 Hartmut W Sager wrote:
I have also been considering several other "roll my own" options for the last few years, notably MySQL/MariaDB/PHP. Being a heavy-duty algorithmic programmer, I am very intolerant of inadequate software, and "roll my own" often becomes my best choice.
That's what I did... roll my own. We're a lot alike, I guess. There's nothing I hate more than spending time learning (and inputting into) new software only to find X number of limitations that are complete deal breakers. I just write my own most of the time, after a quick perusal of the options. I have a complete paperless personal finance tracker (from scanning receipts/OCR through to accounting and c.card reconciliation) I've written in perl/mysql (CLI/TUI based) over the past 8 years or so. Ties into my QB I use for my business too (forced to use "real" software for the business side for various reasons). Saves me a bucket of time. I needed some "weird" features that wouldn't exist in any package anyhow.
If you're wondering why I have to leave FoxPro, it's because Microsoft is letting it disintegrate, despite it still being officially a currently supported product. In fact, as I rudely
Hey, at least you're not in Brad's boat with MS Money, which they officially completely ditched a few years back. Funny that, foxpro outlived Money. If you write your own, they can never pull support on you!! :-) DIY-ers of the world unite! (Off-the-shelfers grumble and relearn!) :-)
That's what I did... roll my own. We're a lot alike, I guess. There's nothing I hate more than spending time learning (and inputting into) new software only to find X number of limitations that are complete deal breakers. I just write my own most of the time, after a quick perusal of the options.
Yes, it looks like we're a lot alike on this. And since I too hate that wasted time of learning and starting to use software that ultimately has dealbreakers, I do all the research and experiments required beforehand, like I'm doing with GnuCash right now.
Ties into my QB I use for my business too (forced to use "real" software for the business side for various reasons).
I have worked a lot with QuickBooks for some clients many years ago, but I refuse to use it for myself due to data entrapment. You can't properly/cleanly export your data from the desktop version, and you can't get your data AT ALL from the online version (Intuit confirmed this to me when I inquired).
Hey, at least you're not in Brad's boat with MS Money, which they officially completely ditched a few years back.
Ouch (poor Brad)! Then again, Money wasn't proper double-entry accounting in the first place. It was Microsoft's answer to Quicken.
Funny that, foxpro outlived Money.
Yes, quite the irony!
If you write your own, they can never pull support on you!! :-)
Yes, I have often made that point to others. Of course, you have to write in a language that will survive (like C/C++), but even if your chosen language dies, you can rewrite your own code into another language and still use the same data files or repository.
DIY-ers of the world unite!
Amen! It's a case of retaining full control of our own stuff. Hartmut W Sager - Tel +1-204-339-8331 On 13 March 2017 at 23:31, Trevor Cordes <trevor@tecnopolis.ca> wrote: [.....]
Just a minor detail; The last version of FoxPro was Visual "FoxPro 9 SP2" (Summer 2007). It went end of support 1/12/2010, and end of extended support (available only if you pay big $$$$) 1/13/2015. https://support.microsoft.com/en-us/lifecycle/search/?p1=7992 John
Yikes! Interesting, thanks. Yes, I have been on FoxPro 9 SP2 for very many years already, but I did not realize that support (even paid) has ended in the meantime. I thought that the support schedule I last looked at some years ago had an end date beyond 2017 for both FoxPro and Access. (Yes, even the future of Access keeps being debated, with no clear statements from Microsoft.) All the more reason I have to leave FoxPro. Hartmut W Sager - Tel +1-204-339-8331 On 14 March 2017 at 16:29, John Lange <john@johnlange.ca> wrote:
Just a minor detail; The last version of FoxPro was Visual "FoxPro 9 SP2" (Summer 2007). It went end of support 1/12/2010, and end of extended support (available only if you pay big $$$$) 1/13/2015.
https://support.microsoft.com/en-us/lifecycle/search/?p1=7992
John
_______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
Actually, to be fair, Microsoft is _very_ clear and open about product life cycles. At the link I provided you can search for any Microsoft Product. For example, if you enter "Access", the first result is "Access 2016", which was the last "on-prem" version. It goes off support 10/13/2020. In reality, Access will be supported far beyond that date because it's now part of the o365 "Pro Plus" product group which gets continual updates and releases. This falls under the "Modern" support policy (the old policy for subscription products is called "Fixed"). Details here: https://support.microsoft.com/en-us/help/4014109 If you want to know what's up with o365, then you go to the roadmap site: https://products.office.com/en-us/business/office-365-roadmap For example, a quick search for "access" reveals that they just recently rolled out: "Add support for 64-bit numbers (BigInt) as a new Access/Ace DataType." and "Connect to external dBASE database, and import or link to dBASE files." So Access is not just supported, but is still being actively developed with new features added, not just patches. It's a pretty safe bet that Access will be supported beyond 2025, though not necessarily the best choice for most projects (see: SQL Express, C#, .NET, etc.). John
Lots more good info from you, thanks! I agree that Microsoft is clear about product life cycles, and generally quite generous with those life cycles too. Now that I see the correct life cycle info, I have no argument with MS re the FoxPro support drop. And yes, I noticed (and already used) that life cycle page to look up a few other MS products. Re MS Office 365, I am actually a subscriber to Office 365 Home, and even that edition includes Access, which greatly influenced my decision to subscribe. I'm delighted with 64-bit BigInt, and will look at all those links you supplied. Thanks again. I recognize that there is still the overall question of what would suite my purposes best. To be, or not to be, MS and/or Windows dependent will remain a question in this whole deliberation. Hartmut W Sager - Tel +1-204-339-8331 <(204)%20339-8331> On 14 March 2017 at 19:50, John Lange <john@johnlange.ca> wrote:
Actually, to be fair, Microsoft is _very_ clear and open about product life cycles.
At the link I provided you can search for any Microsoft Product. For example, if you enter "Access", the first result is "Access 2016", which was the last "on-prem" version. It goes off support 10/13/2020. In reality, Access will be supported far beyond that date because it's now part of the o365 "Pro Plus" product group which gets continual updates and releases. This falls under the "Modern" support policy (the old policy for subscription products is called "Fixed"). Details here:
https://support.microsoft.com/en-us/help/4014109
If you want to know what's up with o365, then you go to the roadmap site:
https://products.office.com/en-us/business/office-365-roadmap
For example, a quick search for "access" reveals that they just recently rolled out:
"Add support for 64-bit numbers (BigInt) as a new Access/Ace DataType."
and
"Connect to external dBASE database, and import or link to dBASE files."
So Access is not just supported, but is still being actively developed with new features added, not just patches.
It's a pretty safe bet that Access will be supported beyond 2025, though not necessarily the best choice for most projects (see: SQL Express, C#, .NET, etc.).
John
_______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
participants (4)
-
Glen Ditchfield -
Hartmut W Sager -
John Lange -
Trevor Cordes