Bug 611936 and the 2.4.0 release

[Mike Evans]

On Monday August 9 2010 20:03:26 Geert Janssens wrote:
> Mike and John,
> 
> Thank you both for your feedback (here and on the bug report).
> 
> I think it's safe to conclude that sqlite3 doesn't fly on Fedora 12 (3
> independent reports so far), it doesn't work on Mandriva 2010.0 either.
> 
> It does work on OS X though, which also uses libdbi-0.8.3.
> Debian is still using 0.8.2 currently.
> It'd be useful to hear from other platforms as well, like openSuSE (at
> least 10.2 ships libdbi 0.8.3).
> 
> Is sqlite3 support on Fedora imporant enough to consider this bug blocking
> for 2.4 ? I would think so as the db support is a major feature for 2.4
> and sqlite3 is the candidate to become the future default backend.
> 
> Do you agree on this ?
> 
> Geert
> 
> On Monday 9 August 2010, Mike Evans wrote:
> > On Monday August 9 2010 11:01:32 Geert Janssens wrote:
> > > On Monday 9 August 2010, Mike Evans wrote:
> > > > What configure option do I need to include sqlite3?  Running
> > > > configure
> > > > 
> > > >  --help doesn't help.
> > > 
> > > That would be --enable-dbi. This will build gnucash with dbi support.
> > > To actually use sqlite3 with dbi, you will need to install the
> > > dbi-sqlite3 driver (it's called libdbi-dbd-sqlite on Fedora 13).
> > > 
> > > Geert
> > 
> > Thanks Geert.
> > 
> > On saving I get a dialog with "The server at URL
> > sqlite3:///home/mikee/Projects/gnucash-mfe/test.sqlite.gnucash
> > experienced
> > 
> >  an error or encountered bad or corrupt data."
> > 
> > Then on reloading  all transactions  are zero.
> > 
> > Error output is lots of:
> >  12:44:03  CRIT <gnc.engine>     xaccSplitSetValue: assertion
> > 
> > `gnc_numeric_check(amt) == GNC_ERROR_OK' failed
> > * 12:44:03  CRIT <gnc.engine>     xaccSplitSetAmount: assertion
> > `gnc_numeric_check(amt) == GNC_ERROR_OK' failed
> > * 12:44:03  CRIT <gnc.engine>     xaccSplitSetValue: assertion
> > `gnc_numeric_check(amt) == GNC_ERROR_OK' failed
> > * 12:44:03  CRIT <gnc.engine>     xaccSplitSetAmount: assertion
> > `gnc_numeric_check(amt) == GNC_ERROR_OK' failed
> > 
> > and several:
> > 
> > 12:44:03  WARN <gnc.backend.sql>     [load_taxtable_guid()] Taxtable ref
> > '5357d7648a50bf2971ae7ebadd337c7e' not found
> > * 12:44:03  WARN <gnc.backend.sql>     [load_taxtable_guid()] Taxtable
> > ref '5357d7648a50bf2971ae7ebadd337c7e' not found
> > * 12:44:03  WARN <gnc.backend.sql>     [load_taxtable_guid()] Taxtable
> > ref '5357d7648a50bf2971ae7ebadd337c7e' not found
> > 
> > Saving as mysql I also get a dialog with:
> >  The server at URL mysql://USER:PASSWORD@localhost/gnucash experienced an
> > 
> > error or encountered bad or corrupt data.
> > 
> > However, the data loads back OK.
> > I hadn't tested mysql for a while so I'm not sure when the problem was
> > introduced but It used to work fine with no error dialog.  I should open
> > a
> > 
> >  new bug I guess.
> > 
> > This is on Fedora 12 with libdbi-dbd-sqlite-0.8.3-5.fc12.i686 and
> > libdbi-dbd-mysql-0.8.3-5.fc12.i686

Originally I thought, ooh a database full of stuff I can query and format in 
any way choose, then ooh, I can do stuff from ZenCart (other online shops are 
available) and write code to directly update GnuCash with sales.  Then I 
thought of the disasters that can occur, especially if an update is made while 
I have GnuCash open, plus those caused by dodgy code.  So I thought maybe it's 
not such a "good thing" as I first thought.  I liked the fact that with XML I 
can make a mistake (and I've made many while learning the system) and not save 
the changes, then revert to the original file.  With mysql I can't, as changes 
are immediate.  Not sure about sqlite as I never thought about it as an 
option.

Further research involving the python bindings informed me I can do sales 
inserts and updates and data extraction without screwing up the saved data 
(?).  This leads me to the conclusion that the safest data storage is the xml 
file.  I like the idea of messing with the data via other mechanisms than the 
GnuCash interface but the risk of data corruption far outweigh any of the 
flexibility afforded by mysql.  As a business user with the obligation for 
accurate and robust record keeping and yearly taxes to pay I am going to stick 
with xml.  Plus I have easily recovered file backups with rsnapshot.  I guess 
that goes for sqlite3 too though?

Saying that, the idea of interfacing with (on-line) sales software appears to 
be the potential "killer app." and if it can be implemented safely would be a 
great seller(?) for GnuCash.  Balancing the merits of data security with 
convenience is never going to be easy and I wonder if GnuCash should go down 
that road.  However, if users are given the choice at least they have a choice 
to make, provided the pitfalls are appreciated by those willing to develop 
peripheral code to integrate GnuCash with whatever application they choose.  
It seems to me that although many users on the mailing list are programming 
literate and are well able to make that choice, many are not and these are the 
ones least likely to be mailing list users and likely most vulnerable to data 
loss.

Just a personal opinion.  I will be using xml for my business accounts.  I 
will be using the invoice/bill importer, as I make purchases from Rapid, 
Farnell and RS.  I will be looking at the python bindings for sales 
connections to web shops but in a purely academic mode as I have no clients 
requiring that functionality.

So in brief.  Since database support is a major feature of the next release 
then yes, it needs to work on all potential platforms.  It needs more 
testers/feedback though and there certainly doesn't appear to enough 
developer/testers for sufficient feedback on this issue on this mailing list.

Rather more information than you requested Geert and a bit rambling but I 
thought I'd sum up my thoughts here.

MikeE

-- 
GPG Key: 1024D/050895C2
Keyserver: http://pgp.mit.edu/          
Search String: 0x050895C2