Derek Atkins wrote:
Umm.. I can't imagine ANY workaround that gnucash would perform that would silently break with a gda upgrade.
The biggest example is a workaround to escape strings not already escaped through the use of prepared statements. There is no reliable way to detect whether prepared statements are supported (apparently), so there would in turn not be a reliable way to detect whether or not the escaping workaround should be applied. If you apply escaping where it isn't required, you get corrupted strings. If you don't apply escaping where it is required, you get SQL insert failures.
Oh, I'm all for getting gda fixed.. But there's a timing issue here. How long does it take to: 1) get GDA to fix the problem 2) get a new GDA release 3) get the new GDA release into the distributions?
Significantly less time than: 1) User experiences sudden corruption of their gnucash file 2) User traces it back to a libgda upgrade 3) Get gnucash to remove the workaround 4) Get a new gnucash release 5) Get the new gnucash release into the distributions.Rather take longer and do it right, than be impatient and sow the seeds of angst, drama and future pain.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
