All Scheduled Transactions Disappear

[Mike or Penny Novack]

On 12/24/2016 5:59 PM, John Ralls wrote:
>> 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.

Negative aspect?  Your backup strategy for the databases used by SQL 
should be for ALL Sql databases on your computer, not just those used by 
gnucash. Yes, perhaps at the moment you are only using SQL with gnucash. 
But it would be wrong (shortsighted) to think of SQL as being something 
that could only be used with gnucash.

Ideally your backup strategy is devised so as to backup all DATA on your 
computer << you need to backup "systems" only with each "build" -- of 
course if you might be randomly updating software without a plan, then 
you have to have regular backup of that too. One advantage of doing 
software changes only with a "build" (all the ones since last time at 
once) is that you don't need to be doing interim backups of software >>

By putting the responsibility into a backup process that handles all 
data on your computer you don't have to remember to change that when you 
add some new kind of data.

Michael D Novack

PS: I assume that there is a backup/restore facility for these "small 
sorts" of SQL just like I had available DB2 utilities to do 
backup/restore of mainframe SQL data. ROFLOL, I once did a "conversion" 
of a set of tables by converting their backup and restoring from that << 
in the middle of development of a new system decided that they needed 
somewhat expanded tables (columns) and more test cases (rows) and it 
takes a lot of people sitting at terminals a lot of time to do that 
manually when you are talking about tens of thousands of test cases >>