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