Your IBM Computer, May-1984

by Lloyd Borrett
Your Computer, May 1984

Most people in the computing community are able to recall the names of some of the more successful microcomputer software products. To many, a spreadsheet program is VisiCalc, not vice versa. When it comes to microcomputer database software, dBase II is the name they remember.

Ashton-Tate's dBase II is one of the success stories of the microcomputing industry. More and more software houses are realising that in dBase II they have not only a relational database, but also a fully-fledged computer language that programmers can use to write application systems. The market for dBase II compatible products has become an industry in its own right.

dBase II was developed for use on 8-bit CP/M machines, and was one of the first programs to be ported to CP/M-86, MS-DOS and PC-DOS when the 16-bit machines were released. The program remained functionally identical to the 8-bit version, and initially made little use of the IBM-PC's screen and keyboard features. Version 2.4 added some useful new features and fixed some of the more notable bugs found in previous versions, but it still did not make use of the extra power of a 16-bit machine.

Naturally, the competition realised this and lately more powerful database products have appeared. Some of these products are dBase II clones, others try to break new ground. As is often the case with new products, many have their own limitations. People have been reluctant to abandon dBase II.

Fortunately, Ashton-Tate does not intend to sit back and watch its market slip away. The company recently announced the development of dBase II 2.6. No public release date was given and it was made clear that certain features of version 2.6 were still tentative.

dBase II version 2.6 will only run on the IBM-PC and compatible machines; that is, it's exclusively 16-bit. It is estimated to be only 80 per cent compatible with current dBase II releases. Some of the features are:

• The ability to have four databases open simultaneously.
   
• Capacity for up to two million characters per record, and up to two billion records per database. (How many years would it take to back up such a database using floppy disks?)
   
• Memory variable space is increased to 6000 bytes and memory names to 256.
   
• Numeric accuracy is up to 15.9 digits. using the IEEE Floating Point Format Standard.
   
• The SET PATH command under PC-DOS 2.0 allows you to set the path to a particular directory or sub-directory.
   
• A TIME function to get the time of day.
   
• The STORE command has been changed to the equal sign (=), working from right to left as it does in most other languages.
   
• The new SEEK command will FIND on a substring of an indexed field.
   
• Square root, natural log, exponential notation, and Julian date to calendar date (and back again) functions are also included.
   
• There is also a new type of field called a text field. This field has an associated text file of up to 4000 characters, modifiable with a new streamlined word processor.

These are but some of many notable features announced. Ashton-Tate is also working on a multi-user version of dBase II 2.6. (No prizes for picking UNIX as the operating system.) dBase II is firmly established as the market leader in the mid-range of database product offerings. If Ashton-Tate can deliver the features announced, dBase II is likely to remain on top of the heap.

Back-Up Procedures

Diskettes (and all other computer storage media) are fragile. It's easy to forget that. You can use a diskette for months with no trouble, but once in a while, just when you least expect it, just when it's least convenient, a problem will occur.

However, you will probably be the cause of the majority of data losses. Many of the DOS commands (ERASE, FORMAT, COPY), if used carelessly, can destroy your data. It's so easy to create files that most people don't appreciate the value of the data until they lose it.

The answer is to make back-up copies. A back-up copy is the only form of insurance available. Take a look at your collection of diskettes now. How many hours have you invested in them? How would you like to have to reproduce them from scratch?

Unfortunately, past experience shows you're unlikely to do anything about back-ups until it's too late. Only when you find yourself in the situation where a file is permanently lost does this sink in. In the mainframe world people are employed to make sure the data is backed up. In the microcomputer world there is only you. The importance of back-ups can't be overstated. So what do you do?

First, divide your diskettes into work, program and project categories. The work diskettes should contain no permanent files. Data on a work diskette is temporary, and doesn't need to be backed up. Any program files on work diskettes can be recovered from program diskettes.

When a new program is received, make a copy of the distribution diskettes. The distribution diskette is then archived and the installation procedures are carried out on the copy. When completed, yet another copy is made and labelled 'Working Copy'. This is the diskette that goes into use. The other diskette is labelled 'Back-up Copy' and filed away.

Should a working copy program diskette become corrupted, you can make a new one from the back-up copy without having to go through the installation procedures again. If both copies fail, make sure your hardware is in full working order before placing a distribution diskette at risk.

The files on project diskettes are related. These need to be backed up, but not always with the same frequency. Project diskettes that contain high-priority work, or current work that is changing often, can be backed up more often. Project diskettes that change little can be backed up less often.

For a simple back-up, the procedure is to:

• get the back-up diskette from storage
   
• copy the working diskette onto it with DISKCOPY
   
• compare the two diskettes with DISKCOMP
   
• return the back-up diskette to storage.

One diskette is always the back-up copy and the other is always the working copy. The working copy gets all the use, all the wear, and is exposed to all the hazards.

A rolling back-up allows the wear and tear to be shared equally by the diskettes. Each time you make a back-up copy, you put the copy back into use and the original is stored. You choose the period between back-ups — be sure to make it often enough.

This scheme creates a single level of back-up. You can expand a rolling backup to have as many levels as you wish. A typical example for valuable diskettes is to have a diskette for each day of the week, thus giving four levels of back-up.

If you think this is overdoing it, then you haven't yet learned the lesson the hard way. Besides, I'm not finished yet. Remember earlier when I suggested the distribution diskettes should be archived?

If the back-up diskettes are kept in the same building with the computer, they are exposed to any disaster that destroys the computer itself. Hardware can be replaced easily, but data cannot. As this is a fairly unlikely situation, you can perhaps allow a disaster-proof back-up copy to be a bit out of date.

In other words, you should keep archived diskettes off the premises, or in a fireproof safe, and regularly take archival copies of your project diskettes.