Hello again DONATION advisors.
I’ve had three or four users relatively recently report missing data within the current year, like “I’m missing all of June and July’s donations, but the ones after that are there”.
Given that there is no feature in DONATION that could possibly mass delete donations like that, the only possibility I can imagine for a situation like that is that at some point in August say, they accidentally (or on purpose, but not understanding what they were doing) restored a database backup from the end of May, didn’t realize that lost them their June and July data, and then just continued data entry from there.
So, I’m working on ideas for some changes to make this less likely.
The first has to do with backups. Currently if your database is the default one, DONATION4.DB, the default backup name you are offered is DONATION4.DB.GBK. You can change that (as long as you leave the ending of “.DB.GBK”), but I’m sure most people don’t.
My idea is to change the default backup filename to be based on the current date, e.g. DONATION2011-12-07.DB.GBK for today’s backup (on December 7, 2011). It could still be changed if desired.
There are two advantages to this. The first is that it will be obvious how old a backup is, that a user is trying to restore (as long as they figure out the YYYY-MM-DD date format, I guess!). The second is that unless the user does something about it, they will have a bunch of backups stored, from all different dates, and each backup will not overwrite the previous one that was stored in the same location.
However, that last point is also a potential disadvantage, as those multiple backups could start filling up whatever storage they were storing it in, e.g. their hard drive or a USB memory key. However, for most users a backup is at most a few megabytes, so it would really take a long time for this to be an issue given the large size of today’s storage.
One option would be to do what some other programs do, and have an option to keep only the last N backups, where they specify the number N (like, last 10 backups). But personally, I think you never know how old a backup you might need. So I’m not sure whether this is a good idea or not.
There could also be an option (on the same window as the one for changing the Backup Reminder Frequency) to go back to the old naming convention, leaving the date part out of the backup filename. But I’m not sure that’s a good idea, as the advantages of the new naming are significant, and the users can always erase the date part from the filename each time they do a backup, if they feel strongly about it.
If I added one or both of the options mentioned above to the Backup/Restore -> Backup Reminder Frequency window, I’d probably rename that menu option to Backup/Restore -> Backup Options.
Now, on to restores. What I’m thinking is that when you go to restore a backup, the program will first open up that backup and find the latest donation date in it. It will compare that to the latest donation date in your current database, and if the backup’s data is older than your current data, it will give a message about it, including stating what each of those two dates is. If the backup data is at least one month older, the message could also say something like “You are about to restore data that is N months older than your current data.” And then of course ask whether they really want to do the restore.
Any thoughts about these changes, and the possible options mentioned above (let them go back to the old backup naming without the date part, and let them specify a maximum number of backups to store in the same location)? As usual, you can Comment on this post to give me your thoughts, or just email a reply. Thank you in advance!