GDA Missing records in SQLite
Mark Johnson
mrj001 at shaw.ca
Sun Feb 24 22:24:32 EST 2008
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 <47BCA52E.6010806 at shaw.ca>, 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
More information about the gnucash-devel
mailing list