[GNC] Deleting Transaction from Reconcile Deletes Wrong Transaction

[John Layman]

My experience is the same as Geert's.  I've seen no performance advantage
when testing XML vs MySQL with my 12 years of data.  The initial load from
db is slower than with XML, and flushing and zipping the data at termination
is reasonably fast.   As for immediate commit to the db, I find that
actually to be a negative, since I do find myself resorting to the 'revert'
feature from time to time.  Except for the case where someone is actually
querying the database for custom reporting, etc. I can't think of any
advantage to using a database with GnuCash.

-----Original Message-----
From: gnucash-user <gnucash-user-bounces+john.layman=ieee.org at gnucash.org>
On Behalf Of Geert Janssens
Sent: Friday, December 30, 2022 10:31 AM
To: David Carlson <david.carlson.417 at gmail.com>; gnucash-user at gnucash.org
Cc: GnuCash List <gnucash-user at lists.gnucash.org>; Adrien Monteleone
<adrien.monteleone at lusfiber.net>
Subject: Re: [GNC] Deleting Transaction from Reconcile Deletes Wrong
Transaction

Op vrijdag 30 december 2022 15:47:35 CET schreef Thomas Forrester:
(snip)
> I use database storage over the XML storage method because it does 
> afford me opportunities that the XML plain text file does not.  I now 
> have data going back seven years in GnuCash and I think that's too 
> much to push on a text file.  At some point the scales tip in favor of 
> a full-fledged database over text file read/write operations.

I haven't followed the rest of this thread, but this paragraph caught my
eye...

The way gnucash works the storage method hardly has any impact on
performance. In all cases the whole data set is loaded completely into
memory when the data set is opened (be it an xml file or a database
backend). And all work is performed purely in memory.

The major difference is that with a database backend, any change you make is
immediately written to the db right after the model in memory has been
altered. With the xml backend, changes are written to the xml file only on
explicit save, or at the autosave interval (if set).

So the load and save experiences may be slightly different (last time I was
involved in this the initial db load was slower than the xml load, but
saving to xml takes more time as it has to write everything at once, yet
that is not done as frequently as saving each atomic change to db
directly...)

But for both the db or xml storage, after the initial read, the data is
never read again from the storage and gnucash will only work with what's in
memory.

Regards,

Geert
_______________________________________________
gnucash-user mailing list
gnucash-user at gnucash.org
To update your subscription preferences or to unsubscribe:
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.