Gnucash versions

[Geert Janssens]

[[ Please send all your replies to the list instead of my private mail. You 
can do so by using the reply-to-all or reply-to-list function of your mail 
client. ]]

On donderdag 6 oktober 2011, Charles Kanavle wrote:
> At 10/05/2011 12:48, you wrote:
> > > I had expected some kind of conversion process in making the transition
> > > to the database back-end - it's probably time to read the
> > > documentation thoroughly...
> >
> >The conversion doesn't happen automatically. If you just open your
> >existing data file with the new gnucash version, it will continue to use
> >the original data format by default. Only if you decide to save your data
> >in a different format (using the Save As menu item) the new format will
> >be used.
> >
> >A friendly word of advice though: if data integrity is your main concern
> >and you don't have a strong reason to use the sql data format, stick with
> >the original (xml) data format for now. It's been more thoroughly tested
> >than the sql data formats. These new data formats work generally well,
> >but there may still be some minor odd ends in rarely used work flows.
> >
> >Geert
> 
> Yup.... I can tell you of one particularly troublesome experience
> with the new SQL, that is, postgresql. I already have postgresql
> installed, because I run postbooks for its manufacturing inventory,
> bom, shop work orders, and invoicing. I don't use the postbooks
> general ledger though because it is horrendous... it acts like a
> steel trap, not letting you recover from ANY typing booboo. So, I use
> gnucash for the GL part, after getting my invoices.
> 
> The glow of getting to use postgresql also for gnucash faded very quickly
> as soon as I eventually hosed the data base (by using the tried and
> proven pgAdmin3 postgresql utility on my data).
This has been stated multiple times by now already: don't expect the data 
GnuCash stores in the database to be a complete self-contained relational 
database. It's a data dump and parts of the relational logic to make sense of 
that data is in the GnuCash code. I know some developers are working in 
improving this, but such things take time. Until GnuCash is at that point, the 
repeatedly mentioned advice still stands: don't manipulate your GnuCash data 
via a tool that's not using the GnuCash code.

> So, I went to my
> latest backup and lo... was I in for a shock. The backup also was not
> readable by gnucash. The only way I had to recover was to laboriously
> re-enter all my data! This took days. I am not a happy camper.
> 
That means your backup was most likely already corrupt. Because I know from 
experience you can make backups (db copy/db dump/whatever) from a working 
GnuCash database.

I'm sorry you lost all that work though.

> I found out online that I should not use pgAdmin3, but what kind
> disgusting crap is that? It was irresponsible to list postgresql
> support in gnucash when you cannot even make a backup that will work.
> I had to abandon use of postgresql, and am now using sqlite3 instead.
> I even saw a post online saying they did not know much about
> postgresql... what?.... hey.... don't say you support it until you
> know what you are doing, and be able to backup your data!
> 
I don't enjoy the tone of this last paragraph. We're all humans, we all have 
the best intentions and yet make mistakes (and that goes for both the users as 
the developers by the way). I don't feel like going into a discussion on who 
is right or wrong and what could have been done better in the past. That's 
only time wasted, time we can better spend improving GnuCash now.

Geert