Phil Longstaff wrote: > Graham Leggett wrote: > >> Phil Longstaff wrote: >> >> >>> There is a function to query the backend to see what features it >>> supports, but prepared statements is not in that list. Also, if we >>> require prepared statements, that might cut out the sqlite backend >>> because a libgda modification to use it might not propagate out far >>> enough. I know Derek wants to see the xml gnucash file replaced by a >>> sqlite db, so we need to be really sure it is unusable before we >>> disqualify it. >>> >> A quick Google search shows a number of references to prepared >> statement use in sqlite, which suggests to me that prepared statements >> are supported. >> >> Two things worry me at this point about the current behaviour of libgda: >> >> - Row inserts are failing, but the error is not communicated back to >> the caller. As a result, the database is corrupted in the process. >> > I'm not sure the error is not communicated back. In an e-mail from Mark > Johnson with msg-id <[EMAIL PROTECTED]>, he said there is an > error message written to /tmp/gnucash.trace. I agree with him that that > is not sufficient warning that there has been a problem. > > Note that on the flip side, the postgresql backend seems to return > normal status as an error indication so that there is lots of stuff in > /tmp/gnucash.trace. > Admittedly, my gnucash.trace file is only from saving to PostgreSQL and not from attempting any use. However, I only see errors and warnings in it. I do not see any successful inserts. Most of the errors relate to the SERIAL problem in the PostgreSQL provider. >> - libgda doesn't seem to (yet) guarantee that prepared statements are >> used, and therefore that parameters do not need escaping. >> >> The data being saved is financial data, and people are using this data >> to file tax returns and various other mandatory stuff that could prove >> expensive if done incorrectly. Gnucash should be treating this data >> conservatively, and should only be using backends that can give some >> kind of certainty that data won't be corrupted for any reason. >> >> If we have to temporarily disable a backend until that backend works >> correctly, it is the safest thing to do, and offers an incentive to >> get the backend fixed. >> > I think I can come up with a libgda patch which will escape/unescape > strings properly for sqlite and I'll submit this to the libgda project. > Makes config mgmt during testing and for gnucash execution more > difficult because because of the dependence on the specific version of > the library, though I suppose there is already this problem with other > libraries. Maybe we can ask libgda to release a 3.0.3 version with this > patch in the near future so that people can test with an official libgda > release rather than a patched one. > I've been trying to cook up a small project to demonstrate this problem. Since you're working on a patch, I'll stop working on this. > Phil > > Mark
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
