All Scheduled Transactions Disappear

aeneas receiver at gowdygroup.net
Mon Dec 26 14:18:16 EST 2016


I've had some success with the recovery operation.  Using the most recent
backup of the DB I was able to drop the tables and rename the foo_back
tables as replacements and open the the resulting DB.  At present I'm unable
to open the new DB using the Linux version of GnuCash that is installed on
the same computer as the MySQL server which is actually the MariaDB that is
supplied with XAMPP.  I haven't had much success troubleshooting this
problem.  While I do think the user permissions are correctly specified I
haven't figured out how to verify that fact.  The message displayed by
GnuCash is pretty general meaning not much help for troubleshooting. 
However, remote access using the Windows version of GnuCash is working. 
While this DB is definitely better than what I had when I first noticed a
problem, I think I have no way of determining whether or not it is complete.

I'm only using a limited amount of the GnuCash capability.  Most of the
tables are empty.  My use primarily involves reconciling bank and credit
accounts.  This makes me think that one test of completeness will be whether
or not subsequent account reconciliations work correctly.  Does that make
sense to you?

I have no knowledge of using GnuCash from the command line.  Have never done
it.

I'm probably missing something here but your explanation of table
replacement causes me to think that absent some kind of failure the DB
should never be found with the foo_back tables present.  In this case they
are not only present but they appear to be persistently present even though
there was no perceptible indication of any system failure.  My best
suspicion about what may have gone wrong is a poor Internet connection to
the DB which was remote.  My Internet service is also asymmetric meaning the
outgoing service needed for writing to the DB is slow even when working
properly.  I don't think I'd have ever attempted this if I knew the DB would
be completely rewritten.

Your remarks about full save trigger some curiosity.  My expectation of a
benefit associated with using a DB management system (DBMS) is that
transactions (maybe updates is a better word) would be committed at the time
each individual revision is done.  The idea being that you don't risk
loosing a lot of work because you haven't performed a save for a while.  In
that, there is no cumulative save operation that needs to be performed that
potentially affects all or most of the data.  My thinking being that this
should improve integrity and minimize loss that comes from system
problems/failures.  Just what is a full save?  How is it triggered?  Is that
what renaming and then rebuilding all of the tables is about?  While I can
appreciate how this concept might fit with the idea of developing a system
that works either with or without a DBMS it is also contrary to the benefits
desired from using a DBMS.  Is that the price we are paying for being able
to use either standard files or databases?  This does have me reassessing
the desirability of using a database.



--
View this message in context: http://gnucash.1415818.n4.nabble.com/All-Scheduled-Transaction-Disappear-tp4688388p4688430.html
Sent from the GnuCash - User mailing list archive at Nabble.com.


More information about the gnucash-user mailing list