Contents

About AIMS Backups

Installation

Data Backups

Application Backups

Restoring Files

The Backup Folder

Backing Up to a CD

Deleting Old Backups

Re-naming Backup Files

Creating a Backup Button


About AIMS Backups

AIMS Backups is an Alpha Five addin created by AIMS DataCom to make it easier for the user to backup data files or application files separately.  The two functions, BkUp_Data_Zip() and BkUp_App_Zip(), also add the ability to backup other files that are not part of the standard Alpha Five backup routine.  See the respective backup information section for details on the additional files.

The backup function will compress all selected files in Zip format and store the resulting zip file in a sub-folder of any drive that can be written to directly.  (See "The Backup Folder" in the table of contents for details.)  Backups will always store all Data or all Application files depending on which one the user selected.  Once saved, the files can be restored either all at once or by selecting specific files.

Contact Information

Copyright © 2002 Cal Locklin, AIMS DataCom, Inc.  All rights reserved.


Contact Information

Address: Phone:	AIMS DataCom 6204 Five Mile Rd. Northville, MI  48167 248-437-5883
E-Mail:	CALocklin@Chartermi.net
Website:	www.aimsdc.net


Installation

The installation file installs two files, AIMS_Backups.aex and AIMS_Backups.hlp, to the Addins_Installed folder under your Alpha Five v5 executable folder.  This makes the backup functions available to any A5 application run on your computer.

If you prefer to have these backup routines available only to specific applications, remove both these files from the Addins_Installed folder and (a) copy them to the application folder, then (b) open the application, go to the control panel, and define AIMS_Backups.aex as an attached compiled library.

WARNING:  If the files are installed to the application folder and the application is run on a network, the .aex file must be copied to the workstation manually unless you are using the free Opt_net_v5() function* also created by AIMS.  At the time this was written, .aex files were not copied by the standard A5 network optimize routines.  If you use the Opt_net_v5() function, the .aex files will automatically be copied each time the files are optimized or refreshed.

* The Opt_net_v5() function is available as a text file in the Archive section of  the Alpha Software message board or as a downloadable installation from www.aimsdc.net.


The Backup Folder

The name of the final sub-folder where the backups will be stored is created by the backup routine.  The format of the backup folder name is "xxx_bkup" where "xxx" is the first 3 characters of the name of the main application file - which has the extension .adb.  Although the name of this final sub-folder cannot be changed, it can be stored under any other folder the user selects.

The initial default for the backup folder is a subfolder of the actual data.  (On the server for network applications.)  However, we highly recommend immediately changing the backup drive to something other than the same physical drive as the original data!  The backup can be stored in any other drive or sub-folder the user chooses as long as both read and write access is available for that folder.

Once the user chooses a folder, that folder will be saved as the default for the next backup or restore operation.  Since the name of the default backup folder is saved in the same folder as the actual data, there can be only one default folder.  Therefore, network backups will work better if everyone's system uses the same drive letter and path for the backup location.  (Mapping drive letters and server paths is a job for the network administrator.)

NOTE:

If this is a network backup and the backup location refers to a drive on a local workstation, for example "C:\MyBackups\xxx_bkup", then the backup file will be put on the local workstation of the person who runs the backup.  This has the advantage of creating redundant backups in case of a catastrophic event but may add some confusion in determining who actually has the latest backup.  In order to determine who has the latest backup, you would need to start a Restore operation from each workstation to get the latest backup date/time info.  Once the date/time info for a specific workstation is determined, the Restore operation can be cancelled and the next workstation checked.


Backing Up to a CD

Backups can only be saved to drives that can be accessed directly with Windows Explorer.  This means that CD backups will not work unless the CD is a CD-RW installed in UDF format so that files can be written or deleted the same as they could be if they were on your C: drive.

In Adaptec CD-Creator, the UDF format is called "DirectCD".

In Nero, the UDF format is called "In-CD".


Application Backups

The AIMS DataCom application backup routine is designed for running daily backups - see note below.  The program developer should create a Backup button for the user - typically on a Maintenance or Utilities menu.  The button only requires one line of code:  Bkup_app_zip().  No arguments are required or accepted by the function.  All available user options are given in the pop-up selection window.

The application backup should not be needed on a regular basis.  This routine allows users to make a backup on their own system if desired for added security in case of a major hard drive failure.  One application backup is sufficient after an application change.  Running additional application backups when the application has not been specifically modified is just a waste of time.

The application backup function will backup all application files (data dictionary files -- .dd*, .se*, and .al* ) from the application directory.  Even files for tables, sets, or application libraries which are not listed within the application itself will be backed up.    This was done because some applications use attached libraries to provide additional scripts/functions and 'external' tables/sets for lookups and other purposes.  While this may result in backing up unnecessay files in a development environment, it usually works quite well for finished applications.

Also, all files in the application folder with the '.aex' extension (compiled Alpha Five addin files) and all .bmp, .jpg, .hlp, .chp, .txt, .asc, .csv and .amq files will be included in the backup.  (The .amq file is included because of a special text file used by the AIMS Network Optimize routine.)

In addition, the developer can include additional files in the backup by listing them one name per line in a text file called "addl_app_bkup.txt".  See Backing Up Additional Application Files.

The other available options are:

- the choice of compacting the data dictionary files before storing them.  The default is "No" since they should not normally be changed by the user.

- selection of a different backup folder.  See Backup Folder for more info.

- deleting all previous application backups in the current backup folder.  This option should only be used if you are using a backup method that recycles previous daily/weekly backups.  See also:  Recycling Backup Media and Deleting Old Backups

NOTE:  Since the name of the backup file is generated by the function and includes the date of the backup, this function is really designed for only daily backups.  You can backup multiple times throughout the day but each new backup will overwrite the previous one unless you use Windows Explorer to change the name of the current backup.  WARNING:  If you change the name, DO NOT change the part of the name that is "_appbkup_" as this is used by the function to verify that you are restoring application rather than data files.


Recycling Backup Media

A typical example of a "recycle" backup would be when 5 zip disks are used - one for each day of the week.  Keeping multiple backups improves the odds of avoiding a few problems:  (1) You find out the backup is corrupted when you need to restore the data, (2) the computer loses power or crashes while running a new backup and the data gets corrupted but the backup isn't complete - you could end up with a corrupted hard drive and no backup, (3) you just discovered a problem that actually occurred a few days or weeks ago but you only have a backup from yesterday.

You should always have a least 2 backup media (tapes, disks, etc.) so you don't lose everything when there is a problem with one of them.  A commonly recommended system involves daily backups that are recycled every week along with weekly backups that are recycled every month and monthly backups that are recycled every year.  This may sound like a lot of work but it's amazing how many problems are not found until more than a month has gone by.

If the backup media is very large, multiple backups could be kept on one but there should still be some type of 'rotation' of the media, even if it is just every week or every month, just in case of a problem.


Backing Up Additional APPLICATION Files

Additional files can be included in the APPLICATION backup by listing them one name per line in a text file.  The text file must be called "Addl_App_Bkup.txt" and it must be included in the same folder as the application's .adb file.

The additional files must be located in either the main application directory or a subdirectory of the main application directory.  If the files are in a subdirectory of the main application directory, include the subdirectory name with the file name.

If the "addl_app_bkup.txt" file exists, the backup routine will prompt the user to include those files.  This was done in case the additional files don't need to be backed up every time.  For example, a subdirectory of photos might exist but seldom get changed so there is no need to waste time and disk space running unnecessary backups of, for example, "photos\*.jpg".  In a case like this, the additional files might only be included once a week or once a month or when the user knows new files have been added to the directory.

Wildcards (* or ?) are permitted in the file list.

EXAMPLES:

'The following adds two specific .bmp files from

'the "photos" subdirectory to the backup list

'-----------------------------------------------------

photos\picture1.bmp

photos\picture2.bmp

'This adds all .bmp files in the "photos"

'subdirectory to the backup list

'------------------------------------------------------

photos\*.bmp

'This adds all files in the defined

'subdirectory to the backup list

'------------------------------------------------------

property_photos\*.*

'This adds all .xyz files in the main

'application directory to the backup list

'------------------------------------------------------

*.xyz

HINT:  You can turn the application backup into a full backup of both the application and the data files by specifying *.* in the Addl_App_Bkups.txt file. HOWEVER, you should be aware that this makes it much easier for a user to restore a data file by mistake thus losing important data. For example, the user might intend to restore the data dictionaries for the Members table and accidently include the .dbf file when intending to select only the .ddd, .ddm, .and .ddx files.


Data Backups

The AIMS DataCom data backup routine creates a backup zip file that contains only the data.  The file name includes the backup date - see note below.  The program developer should create a Backup button for the user - typically on a Maintenance or Utilities menu.  The button only requires one line of code:  Bkup_data_zip().  No arguments are required or accepted by the function.  All available user options are given in the pop-up selection window.

The data backup function will backup ALL data files (.dbf, .fpt, and .cdx) from the application directory.  Even tables which are not listed within the application itself will be backed up.  This was done because some applications use external tables for lookups and other purposes.  While this may result in backing up unnecessay files in a development environment, it usually works quite well for finished applications.

In addition, the developer can include additional data files in the backup by listing them one name per line in a text file called "addl_data_bkup.txt".  See Backing Up Additional Data Files.

The other available options are:

- the choice of backing up the index files or ignoring them.  The default is to back them up and this is generally the recommended method.

- selection of a different backup folder.  See Backup Folder for more info.

- deleting all previous data backups in the current backup folder.  This option should only be used if you are using a backup method that recycles previous daily/weekly backups.  See also:  Recycling Backup Media and Deleting Old Backups

NOTE:  Since the name of the backup file is generated by the function and includes the date of the backup, this function is really intended for backups that occur only once a day.  See Re-Naming Backup Files for other options.

WARNING:  If you change the name, DO NOT change the part of the name that is "_databkup_" as this is used by the function to verify that you are restoring data rather than application files.


Backing Up Additional DATA Files

Additional files can be included in the DATA backup by listing them one name per line in a text file.  The text file must be called "Addl_Data_Bkup.txt" and it must be included in the same folder as the application's .adb file.

The file extension MUST be included on each line.  This means that backing up a file called mydata in the other_info subdirectory that includes both data, an index file, and a memo file must have three lines in the "Addl_Data_Bkup.txt" file:

other_info\mydata.dbf

other_info\mydata.fpt

other_info\mydata.cdx

Only files that are in a subdirectory of the main application file can be added to a data backup.  All standard data files in the application directory itself are already backed up by default.

Since photos could be considered a type of 'data' when used for something other than a background or logo on a layout, both .jpg and .bmp files can be included in the "Addl_Data_Bkup.txt" list - as long as they are in a subdirectory of the main application.  All .jpg and .bmp files that are in the main application directory are assumed to be used only for backgrounds or logos and are backed up as part of the application backup.

If the "addl_data_bkup.txt" file exists, the backup routine will prompt the user to include those files.  This was done in case the additional files don't need to be backed up every time.  For example, a subdirectory of photos might exist but seldom get changed so there is no need to waste time and disk space running unnecessary backups of, for example, "photos\*.jpg".  In a case like this, the additional files might only be included once a week or once a month or when the user knows new files have been added to the directory.

Wildcards (* or ?) are permitted as part of the main file name.

EXAMPLES:

'The following adds all .dbf files from the "other_info" subdirectory

'to the backup list but ignores the index (.cdx) files.

'---------------------------------------------------------------------------------

other_info\*.dbf

other_info\*.fpt

'The following adds two .bmp files from

'the "photos" subdirectory to the backup list

'-----------------------------------------------------

photos\picture1.bmp

photos\picture2.bmp

'This adds all regular data files in the "photos"

'subdirectory that begin with "region1" to the backup list

'-----------------------------------------------------

photos\region1*.dbf

photos\region1*.fpt

photos\region1*.cdx


Restoring Files

Restoring files should be self-explanatory.  Files are restored by starting the same backup routine (i.e., clicking the same button) that was used to create the original backup (application or data) and clicking the "Restore" option.  You can also change the backup directory* if the default is not correct; i.e., you are looking for a backup that was stored in a different location than the current backups.

When you click the OK button, you will be presented with a list of all the backup files currently in the selected backup directory.  The most recent applicable backup will be selected by default.  Select a backup file to restore data from based on the Restore type (Application or Data) and the date as shown in the file name.

After selecting the backup file, you will be shown a list of all application/data files that are were stored during that backup.  Choose "All" to restore all files or select specific files to be restored.

The default Restore folder will always be the current data location but you can select a different folder in the Select Restore-to Folder window.

WARNING: If you select both "All" and one or more specific files in the file list, only the specific files will be restored.

Be sure to read the instructions on the backup/restore selection window about which files should normally be restored in groups.

*NOTE:  Whenever you change the backup directory, the last selection becomes the new default for the next backup/restore operation.


Deleting Old Backups

Old backups are best deleted by clicking the "Delete Old Backups" button and right-clicking the file to be deleted then selecting 'Delete' from the drop-down window that appears.  When all desired files have been deleted, click the Cancel button to return to the main backup window.  (Of course, old backups can also be deleted with Windows Explorer or any similar file management utility.)

BE SURE YOU DO NOT DELETE ALL PREVIOUS BACKUPS AVAILABLE.  You should generally have at least one backup from the previous week and one from each of the last few months - preferably on a separate drive, disk, tape, or CD.  It's amazing how often problems are not discovered for over a month.

Old backups can also be deleted with the "Delete All Previous Backups" option but this option should be limited to backup systems that recycle multiple backup media (like Zip drives) and are likely to run out of storage space.  See Recycling Backup Media for some important details.


Creating a Backup Button

The backup button could be a one-line script that is simply:

Bkup_data_zip()

However, if you want the user to be able to backup both data files and application files, you would need a second backup button for application backups:

Bkup_app_zip()

A better method might be to combine them both on one button:

resp = ui_get_list( "SELECT BACKUP TYPE", 1, "Data Backup", "Application Backup" )

SELECT

   CASE resp = "Data Backup"

      bkup_data_zip()

   CASE resp = "Application Backup"

      bkup_app_zip()

END SELECT


Re-Naming Backup Files

Since the name of the backup file is generated by the function and includes the date of the backup, this function is really intended for backups that occur only once a day.  However, it is possible to backup more frequently...

To re-name a zip file so additional backups can be saved on the same day, either:

1.)  click the "Delete Old Backups" button, right click the desired filename and select Rename from the drop-down list.

2.)  use Windows Explorer to change the name of the current backup.

Of course, if you don't want to save the previous backup, you can just accept the default to Overwrite and Lose Previous Backup.

WARNING:  If you change the name, DO NOT change the part of the name that is  _databkup_  or  _appbkup_  as this is used by the function to verify that you are restoring either data or application files respectively.