Unattended Backup

[madtowng]

I am trying to leverage the ability of Alpha5 to perform a backup of the entire database (multiple table), preferably without any user interaction.

If necessary, I would like Alpha5 to close any open forms or browses. Warnings to users are not desired at this point.

I considered using a5_zip_db_dialog(), but do not find any documentation for the command.
I would consider using a5_zip_files_w_fback() but somehow think it will require user interaction.

Can someone please tell me how these commands work ?

Thanks much,

Gregg

[Keith Hubert]

Re: Unattended Backup

Hi Gregg,

At what time did you want this unattended backup to happen?

[CALocklin]

Re: Unattended Backup

I wrote the AIMS Backup routines back in v5 before Alpha had its own backup routines. I still don't like the built-in routines because I'm pretty sure they require you to close all the tables before running the backup and they do require at least some minimal setup for each application.

I use the file.zip() command like this:
file.zip( datapath + zip_name, file_list, "d", datapath )
in my routine and have never experienced a bad backup as the result of running a backup while others were using the database. I can't say it will never happen - only that I and many of my customers have been using it since at least 2002 and I have never heard of a problem yet.

That may be the key you need to develop your own.

FWIW: My backup routine also makes a great "developer backup" for developers that have multiple apps and/or help others with apps. Just put the aex file in your Addins_installed folder and it will backup any application by just opening the app, going to the Interactive Window, and typing Bkup_app_zip() or Bkup_data_zip() and clicking OK - no other setup required. (I don't see any reason to force users to backup the complete application so I separated it into two routines - one for developers to use for app backups and one for data backups.) Of course, my routines do include a 'restore' option.

CONSIDER THIS:
I have never considered making the backup run automatically with NO user intervention but I'm sure I could do it. However, I'm not sure it's such a good idea. Either (a) the developer would have to then set the folder where the backup file would be saved, make the decision whether or not to include any other files listed in the "additional files" file, and whether or not to overwrite a previous backup by the same name (see below) or (b) the user would have a button to set up the parameters and would have to set them up before running the first backup. Personally, I would rather let the user at least set up the backup path so they don't have to call me every time they want to make a change - and they will find a reason to make a change.

Actually, my preference would be to leave it as-is and let the user initiate the backup. On one application I have a big red warning that appears on the main menu if the last backup was more than a few days ago. If you wanted, you could even pop up a dialog that won't close until they run a backup.

If you take the backup completely out of the user's control, (1) they won't even know it's there, (2) they might shut off the computer right in the middle of a backup and that will destroy the zip file, and (3) it would have to be stored on the local drive because the user wouldn't know when to plug in an external drive/stick. Storing a backup on the local drive doesn't work very well when the drive crashes. Of course, you could assume that the external drive (or perhaps the server) will always be plugged in but then (a) you should still have some type of user warning if it isn't accessible for some reason and (b) lightning or a huge electrical spike is liable to destroy the external drive at the same time it destroys the computer.

*NOTES:

1. My routine saves the backup to a file name that includes the date. If another backup is run on the same day it will overwrite the first backup. The only way to get around that is to rename the original file before running the next backup. This was done on purpose. I chose not to just add a 1, 2, 3, etc. suffix because I see little reason for a user to keep multiple backups on any given day. In the rare instance where I need to do that - typically because of some special testing or editing - I just rename the previous file manually.

2. My routine only backs up files from the main application folder. It does not recurse subfolders.

3. The web page says it works for A5v5 through v8. It works through v10 as well BUT it only backs up the native .dbf files. It's not designed to backup other db backends.

[madtowng]

Re: Unattended Backup

The way I have it setup now, the backup should take place shortly after midnight on the day the database is to be setup.

I have a script set to fire using the ontimer() command on a control form.