[GNC] Deleting Transaction from Reconcile Deletes Wrong Transaction

[Thomas Forrester]

Thanks for your opinions and experiences on the method of storage
employed.  My perceptions on the pros/coms of either storage method
notwithstanding, it is not the topic of this discussion.  Rather it was
just a side note on the complexities or applicability of restoring to get
around the fact that the program, for some unknown reason, deleted records
that were NOT being explicitly targeted for deletion.

Thanks.

On Fri, Dec 30, 2022 at 2:24 PM John Layman <john.layman at laymanandlayman.com>
wrote:

> 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.
>
> _______________________________________________
> 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.
>