PRODUCT   :  R:BASE                  VERSION      :  3.1
   From William B. Driskell, 6536 20th Ave N.E., Seattle, WA 98115. Bill
   is a marine biologist and computer consultant. You can reach him at
   It has been suggested in half-jesting tones that all new database
   managers should have their knuckles tattooed with that ubiquitous
   phrase, "BACK IT UP!" Unfortunately, the exclamation point requires an
   extra knuckle so the scheme loses its emphasis.
   In total seriousness, every installation should have standard backup
   procedures tailored for both ordinary and extraordinary activities. A
   daily backup is probably good enough for most firms with a routine
   workload but perhaps not adequate during those deadline-tomorrow-
   gotta-work-all-night sessions. During such high intensity data grinds,
   it would be prudent to backup your databases at more frequent
   intervals - by work stages or elapsed work time.
   Making Local Backups
   What if your system operator only runs a tape backup at 5:00 and then
   goes home? Use local backups to reduce your exposure to data disaster.
   For example, copy your database to a different drive to help eliminate
   hardware risk or copy your database to a different subdirectory to
   safeguard against file management blunders.
   If you're tight on disk space, use a file compression and archiving
   utility like PKZIP from Phil Katz to reduce the file size. Typically,
   PKZIP can reduce the size by up to 70%.
   Personally, I find it convenient to maintain local copies of my active
   databases in a subdirectory called BACKUP. If I accidentally delete a
   table or change the wrong set of rows, I have a choice. I can either
   manually correct my errors or replace the table from the backup copy.
   I have a procedure for maintaining local backups. Typically, as soon
   as I finish importing a data set or making major edits to a database,
   I exit from R:BASE and quickly check the integrity of the database by
   using the RBCHECK or AUTOCHK program. Once I know the database is
   good, I use RELOAD to create a backup copy of the entire database in
   the BACKUP subdirectory.
   I verify that the backup is good by using RBCHECK or AUTOCHK. Then I
   compress all three .RBF files in the BACKUP directory into a single
   .ZIP archive file using PKZIP, copy the .RBF files back over the
   original database, and delete the backup RBF files.
   Checking & Fixing Databases
   You can use either RBCHECK or AUTOCHK to review the structure and data
   files (database files 1 and 2), looking for a variety of internal
   inconsistencies. RBCHECK comes with each copy of R:BASE 3.0 or 3.1. If
   you have R:BASE 3.1B, you can use the AUTOCHK program instead of
   RBCHECK. Other R:BASE users can get AUTOCHK by purchasing a new
   utility program named R:SCOPE from Microrim.
   You can use R:SCOPE to fix databases and to rummage around inside a
   database. You can fix databases manually or use the AUTOFIX feature to
   fix them automatically.
   Using RBCHECK
   RBCHECK displays a lengthy list of verifications as it goes through
   table by table, column by column. It displays cryptic technical error
   messages. RBCHECK really spits out more information than you need for
   non-problem databases. You really only need to see the two summary
   lines that display the number of errors found in files 1 and 2. The
   remainder of the display is important only if an error is found.
   Therefore, I wrote a DOS batch file (CHK.BAT) to run RBCHECK, store
   the display in a temporary file, and use the DOS FIND command to
   retrieve the error summary lines. Enter the following at a DOS prompt
   to run it:
     CHK dbname
   Here's CHK.BAT:
     @ECHO OFF
     RBCHECK %1 >errors
     FIND "errors for File" errors
     DEL errors
   The RBCHECK program in R:BASE 3.0 and 3.1 requires the owner password.
   To run RBCHECK automatically, you must put -U on the front of the
   owner password, and specify it on the command line like this:
     RBCHECK -Uownerpw dbname
   If there is an owner password, use this format to send the output to a
     RBCHECK -Uownerpw dbname >outfile
   If there is no owner password, use this format to send the output to a
     RBCHECK dbname >outfile
   Blunder Insurance
   Use these tools to set up your own blunder insurance program. To
   retrieve a table, change to the BACKUP subdirectory, and use PKUNZIP
   to restore the archived database. Then open the backup database, set
   NULL to -0-, and use OUTPUT and UNLOAD to unload the table into a
   file. Edit the DEFINE statement in the unloaded file to match the
   original database name. Then open the original database, use DROP or
   RENAME to delete or rename the original table, and use INPUT to load
   the file.