Backing up Alpha FOUR files Once you start acquiring a substantial amount of data in your databases or you have taken the time to design a set or application that works well for you, you don't want to take chances with all your work. Backing up your data is essential. Although full hard drive crashes are relatively uncommon, they do happen. More likely is the possibility of loosing one or a few files due to a variety of causes and it is just a matter of time before you loose at least one important file associated with your databases. Having a recent backup will save you much frustration and hours and possibly days of work recreating the data if this is even possible. This document will cover what you need to know about Alpha FOUR files to keep your data backed up. The software you use to perform the backup is up to you. There are many very good backup programs on the market and you can check with your local software dealer for their recommendation. Where are the data files stored? Although you may store your database files anywhere you wish, we recommend that you use a directory under the \ALPHA4V2\ directory (called \ALPHA4\ in version 1) to store your data files. You can store your data files in the \ALPHA4V2\ directory along with the program files, however it is much easier to backup and copy the data files if they have been stored in a separate directory. C:\> (root directory) \ALPHA4V2\ (directory containing program files, called \ALPHA4\ in version 1) \ALPHA4V2\DATA\ (directory containing database files) \ALPHA4V2\JOAN\ (directory containing Joan's database files) A good way to find out where your data is stored is to open that database within Alpha FOUR by selecting (from the main menu) Choose, Open. If you had your database loaded when you did this, Alpha FOUR will show you the directory of files located in the current data directory which should include the database you were in. Note the Drive/Path information at the top of this screen. This displays the name of the directory that contains all the files shown on the screen. See the reference manual under "Open a database" for more information on navigating this directory screen. If all your data files are not shown on this directory (use the arrow keys to scroll up and down), it could be that other important data files have been stored in another directory. Which Files to back up The following list contains the files that you are most likely to want to keep backed up. Don't let the plethora of file extensions get you down. Notice that the majority of files associated with a database share the same filename. This way you can just specify to copy/backup all files with that name regardless of the extension (filename.*). In this chart filename refers to the name of the database or set. File Notes Ver 1 Ver 2 Data file. Contains all the records filename. filename. from your database dbf dbf Memo fields. Contains the contents of filename. filename. any memo type fields. If dbt dbt you have no memo fields in a given database it will not have a .DBT file. Index files. Note that the index files indexname indexname associated with a database .ndx .ndx do not share the database name. Index files can take up a lot of space and are usually easily recreated. You may want to ignore the index files when backing up unless you are backing up a set. Form Layout. Contains the screen layout filename. filename. you see when you choose V I4x INx for View. Note this is not your actual data but controls the way the data is shown. Browse Table Contains the screen layout filename. filename. Layout. you see when you choose B B4x BNx for Browse. Note this is not your actual data but controls the way the data is shown. Mail Label filename. filename. Layout. L4x LNx Report filename. filename. Layout. R4x RNx Letter Note that the letter files letternam letternam files. are not associated with a e.LTR e.LTR specific database and therefore do not necessarily share a name with any database. Field Rules. filename. filename. RL4 RLN Range filename. filename. Definition. G4x GNx Saved Search filename. filename. Criteria S4x SNx Saved Global (version 1.1 and above) filename. filename. Update U4x UNx Criteria. Set file. This is the set design setname.S setname.S only. Databases and indexes ET ET associated with the set are stored in their own separate files. Application Application and macros. Any appname.A appname.A file. scripts played through an P4 PP application are saved in their own separate file. Application If your application uses a appname.A appname.A Banner custom banner make sure to S4 S4 Screen. include this file in any backup. Script files Each script is stored in a N/A scriptnam separate file. If your e.SCP script(s) refer to other scripts, make sure to also backup the called script. This list is by no means all inclusive. It represents only those files that are the most closely tied to the data and would take you the longest to recreate should you loose the original files. For a more comprehensive list of all the data files used in Alpha FOUR, consult the reference manual. Three backup options If you would like to backup your Alpha FOUR files the first thing to decide is how complete you want your backup to be. The Quickie backup described below will take less time and disk space but will only backup the essential data files. A full data backup will take more time and disk space but will give you a full backup of all data files and related files which may be more useful should you loose the original. Quickie backup (just the data files) If you are concerned only about keeping an extra copy of your data, consider only backing up the filename.DBF and filename.DBT files. You will not have a backup of your layouts, field rules etc, however, if the database becomes corrupted you still have an extra copy of the data. This represents the most time/space efficient backup. Mid-Level database backup (including layouts and other associated files) If you also want to also back up the database's layouts (forms, browse tables, reports, mail labels), field rules, range settings, saved search criteria, and saved global update criteria, you can backup/copy all files that share the filename with that database. Most backup programs accept the DOS wild card filename.* and this will back up these files as well as the data files covered by the quick backup. This will not backup the index files or the letters. Full data backup (all files associated with a database or set) For a full backup of all files associated with a database you can either backup the entire directory containing the database(s). This would also backup all other databases in this directory. If you want to specify which files to backup, you can backup the following files: filename.* all files sharing the database name indexname.NDX do this for all indexes associated with that database lettername.LTR do this for all letters used with that database setname.* all files sharing the set's name (if you are backing up a set). Note on Sets: When copying or backing up a set it is important to copy all pertinent files from all databases associated with the set. Remember to backup/copy the indexes you use to link the databases together. Sets can also have their own field rules, forms etc so it is a good idea when backing up or copying a set to copy all files that share the set name (setname.*). Also remember to copy all of the set files to the same directory. A set cannot refer to files in another directory. Note on applications: When copying or backing up an application it is important to backup/copy all pertinent data from all databases associated with the application. If the application does not change, for subsequent backups you can simply copy the database(s) without needing to re-copy the application file. It is also important to copy any script files (.SCP) or banner screens (.AS4) that are used in the application. Note on scripts: Script files all have an .SCP extension. Backing up or copying script files is simply a matter of copying all SCP files (*.SCP) in the script path directory. If a script refers to another script remember to also copy that script file. Questions Q How often should I backup my files? A Often, but "often" can be interpreted differently depending on how much you would be willing to loose if the files became corrupted. Data problems can happen anytime and it is a good idea to implement a backup schedule that is based on how much data entry/changes you do in a given time period. Ask yourself this question "If my hard drive crashed today and I lost all the data on it, when did I do my last backup and was the data I lost (since the last backup) worth the time I saved by not backing up more frequently?" Based on your situation, determine how much data you would be willing to loose (1 day, 1 week, 1 month). and weigh this against the time it takes to backup. In most cases you can automate the backup process and make it quicker so you will be willing to do it more frequently. Note: If your database has become corrupted, Alpha Software has a document specifically on database corruption that is available by contacting the tech support department. Q What's the difference between backing up files and copying them to another place? A Usually a "backup" is a compressed version of the original file. By compressing the file, the backup software allows you to store more information on the backup medium (usually a floppy diskette) than if the files were simply copied. The backup program can also handle splitting larger files between two or more disks which is usually not possible with a simple copy. Q When I lost my data due to a hard drive crash, I copied the backup files onto my hard drive but Alpha FOUR would not recognize them. Why? A If you did indeed backup your files, no-doubt the backup program compressed the files and you need to restore the backed up files to the hard drive rather than simply copying them. Properly restoring the backed up files uncompressed the files into their original usable format on the hard drive. Notes on preventing data corruption The best way to prevent loss of data is to avoid data corruption in the first place. Here are some suggestions to help you avoid potential problems. Check your disk for viruses regularly. There are some good virus detection programs available for doing this. Make sure that you always have the latest version of the software because new computer viruses crop up regularly and the software is constantly being updated to recognize the new viruses in circulation. In the Alpha FOUR default settings, set "auto flush" to yes. Setting this to yes ensures that no more than the last record is potentially lost should your computer crash during data entry or experience memory problems. With Auto flush set to yes, Alpha FOUR copies each record down to the hard drive when you press F10 to save the new entry. Without this, Alpha FOUR collects new records in memory and only "flushes" them to disk when the memory gets full. To get to the default settings, from the main menu choose Other, Configuration, Default settings. We recommend that you make a backup or copy of the database before performing the following operations. These operations do not corrupt files but they permanently change the data and therefore posses the greatest potential for data loss if the user does not know how to properly implement them. It is always a good idea to have a backup just in case you misjudged the result. Global Update (unless you are updating a brand new field) Reconfigure Re-evaluate field rules Pack Post Zap