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:passw...@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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
