SQL BackEnd Clarification

[Russell Mercer]

Derek,

To be clear then, what you are saying is that even though the SQL backends
like SQLite, MySQL or PostgreSQL have been offered as equal storage options
to the basic .xml file, the reality is that a potential for data loss
exists for them that does not exist for the .xml storage?

It seems to me that if the potential for data loss exists by using the
alternate storage formats, this should be clearly noted in the
documentation.  I would hate to be the new user that starts with the
software, enters a large amount of data into an sqlite format, for example,
and then loses data, as you say, because they happen to hit one of the
bugs.

I completely understand that this is an all volunteer operation and that
the ability to address bugs is limited by the time that you and the other
programmers have to devote to the product.  Don't mistake this for not
being appreciative of that, because the work you have done is tremendous
and the product is fantastic.  At its most basic, it would seem that being
able to enter data and have it be saved in a regular manner is of extremely
high importance, to the extent of being expected functionality.  If using
an SQL backend means that there are cases where saving does not always
occur and data loss could happen, that should be clearly noted that these
are not stable formats and the only recommended storage file type for
consistent saves is .xml.

I hope I'm not taking this out of context and blowing it up into more than
it is.  What may seem like something small to you from a developer
standpoint looms large to me when I hear that my data may not all be saved
in an SQL backend, when I think it is being saved.

Thanks,
Russell


On Mon, Dec 2, 2013 at 7:12 AM, Derek Atkins <warlord at mit.edu> wrote:

> Klaus Dahlke <klaus.dahlke at gmx.de> writes:
>
> > even if I repeat myself: I run gnucash for pure home/private purposes
> > with the SQL backend (postgres) since many years with no problem or
> > inconsitency at all. My main reason to do it: it is easier for me to
> > write my own reports using either SQL or script language with
> > accessing the database via ODBC or similar (read only!)
>
> The fact that you're had no data recording issues so far only means that
> you're lucky you haven't hit them.  There *HAVE* been a number of them
> found over the years.  Clearly either:
>
> 1) Your usage of GnuCash hasn't hit one of the bugs, or
> 2) You have hit the bug but haven't noticed your data loss.
>
> > Best regards,
> > Klaus
>
> > Please remember to CC this list on all your replies.
> > You can do this by using Reply-To-List or Reply-All.
>
> -derek
>
> --
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        warlord at MIT.EDU                        PGP key available
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>