All Scheduled Transactions Disappear

[John Ralls]

> On Dec 24, 2016, at 12:44 PM, aeneas <receiver at gowdygroup.net> wrote:
> 
> John,
> 
> First, this experience proves the merit of your suggestion about devising
> more proactive backup.  I'll definitely be looking for an improved method. 
> This is actually one of the negatives associated with using MySQL.  In that,
> the backup will have to be a separated from the use of GnuCash.
> 
> Thanks for the tip about renaming.  My mind was thinking there ought to be a
> way to salvage the data but I had know idea it could be so easy.  I will
> give it a try for purely academic reasons if nothing else.  I did make a
> backup of the problem DB which provides me something to play with.
> 
> I've also been in touch with my hosting service and they were able to
> restore the DB to a state prior to when I became aware of any problems.  I
> haven't spent very much time with it yet and will make a backup before
> accessing it with GnuCash.  However, using phpMyAdmin I do notice that my
> Scheduled Transactions now appear to be in the schedxactions table as I
> think they should.  I also noticed the presence of the complete set of
> foo_back tables and your explanation suggested they should have been
> dropped.  Is it possible that they don't get dropped until GnuCash wants to
> do the next rename?  In that, my restored DB has a problem if they are not
> supposed to be present but keeping them around lends itself to this type of
> recovery at the cost of more storage consumption, which could be considered
> desirable.  One might think that GnuCash could offer some recovery options
> by retaining the tables.  Might developers be working on some such
> capability?

The tables should have been dropped at the end of the full save. I can think of two reasons why you might still have the foo_back tables, and you can easily resolve which is the case by comparing the last entry in the transactions_back tables now in your hosted DB and in the backup that you made. If the last entry from the restored database is older than that in your backup then this interrupted full save has happened before but you didn't notice; if the dates are the same then the restoration process probably dropped the tables and recreated them rather than dropping the whole database.

Rather than leaving the foo_back tables around I think we need to detect them and put up a warning box telling the user to make a full backup, then when the user is ready do the drop-and-rename. We absolutely shouldn't be relying on the user to notice that he's lost data!

Something else bugs me about this: The database should have been locked if a connection broke the full save. Did you have to "open anyway" when you started GnuCash?

Regards,
John Ralls