Keep Your ADAM Running
Part VI: Databases on the ADAM
by John Burns

EDITOR'S NOTE: This is the first installment of the sixth and final part of this series by John Burns subtitled "Beginners Guide to Research and Selection". This series was originally published in the Metro Toronto ADAM Group (MTAG) Newsletter, and was made available to us by Richard Clee. This first installment of part six discusses the basics of what a database program can be used for and how to go about setting it up for your own needs as well as things to watch out for. Next month, we will conclude this article and series with the second installment that deals with ADAM only database programs. Although a number of the ADAM programs he covers are no longer available, we will try to fill in the holes for you with more up-to-date details.


What's a database? You hear all kinds of talk about them and you know they refer to a lot of computer stored information, but what are they really?

A database is nothing more than an electronic stack of filing cards with standardized information titles on any subject entered on them. The database will not only deal the cards out in piles (search for a subject) but will extract, assemble and collate information lines from each card (report generation).


You create a database by entering information into the computer in the same way that you would make up a Christmas shopping list and a birthday card list on all your friends. You could make two or three different lists covering, say, birthday cards, Christmas cards or Christmas gifts, but the way most of us do it, especially if we're doing it over a period of time, is to first try making listings on a page and when we discover that isn't flexible enough, we go to filing cards and make up one card on each friend. On that card you could insert their name, address, phone numbers, likes and dislikes, hobbies and birth date, when they last entertained you, whether they sent you a birthday present or whatever. When it came time to send the gifts or decide who got just a Christmas card, you would go through the FILE drawer and make selections from the RECORD cards, stacking the cards into BATCH piles, according to the information contained in the headings or FIELDS. The problem arises when you have somebody who should be selected for more than one card pile and you only have the one card. What do you do about the friend who has a birthday in December.? His record card is already in the pile for those who get a Christmas gift. Oh, Oh. Now you have to start creating duplicate cards. That's the hard way. Enter the tool of the century, the computer database.


A database WILL NOT eliminate the drudgery of typing the RECORD cards or creating the information FIELD headings on your friends. It won't make the gathering of the information any easier or quicker. In some cases, entering that gathered information into the computer FIELDS takes even longer than just making up filing cards because you are locked into certain information formats. Because no computer is as flexible, as easily prompted or association-memory riggered as is the human brain, you have to be exact and painstaking in the creation of the headings, questions or information FIELDS on your RECORD cards. You have to remember to do things (the entries) the same way every time just like training an animal. If you don't do it the same way every time, the poor thing gets confused and can't give you the results you want.


For example, you have to decide, once and for all, how you are going to enter something as simple as DATES. Suppose you want to enter the 19th DAY of the MONTH of March in the YEAR 1990. Your first reaction is, "That's simple." Really? Consider again. Will it be entered as Mar19/90; 19Mar90; 19,03,90; 3/19/90; March 19-90 or March 19th, 1990 or full numeric such as 031990? The more recognized conventions are the American Date Presentation Format of MM/DD/YY, the British format of DD/MM/YY and the ANSI format of YY.MM.DD. There are also French, German and Italian formats. Database program manuals seem to suggest using the ANSI format because the date is arranged in proper sort order and makes for easier handling by the micro-processor (I presume easier equals faster). Regardless of which you use, the human brain would look at them and recognize all as variations of the same date, even if mixed up. ADAM can't handle that mix up and not many computers can. Most computer programs don't care how you enter information, as long as you do it the SAME WAY, EVERY TIME.


It is this sort of petty pickiness that sometimes deters people from using or creating a database. They just can't be bothered. On the other hand, for those disciplined individuals who are willing to put up with the pickiness of computer entry input, there are great benefits. A database will intake all your information (known as RAM DATA) one time then select, manipulate and display it in many ways and many times. It could be by the FIELDS of alphabet, by location, postal code, telephone number, likes, dislikes, shoe size, the number of children or whether they sent you a gift last year. You can quickly decide who gets the gifts and who gets only the greeting [SELECT THOSE WHO SENT ME A GIFT LAST YEAR]. You can print out lists, generate mailing labels or send a personalized form letter to some or all of them and do it FAST!


For computer APPLICATION USERS who are not into programming, a database can be a real business or education tool. It can be trained (or the operator can be trained) to handle anything from a simple customer / prospect list to the operation of a completely cross-referenced encyclopedia with index (Not recommended on ADAM!). It will handle character or text information, numbers and logic questions.


It can handle business inventories or production solutions. [HOW MANY QUARTER INCH BOLTS IN BIN No. 4 AT LAST INVENTORY?], [HOW MANY QUARTER INCH BOLTS IN TOTAL INVENTORY NOW?] For that repeat order of Widgets, it can remember (and you can locate!) the final production settings that worked best on milling machine No. 3 to produce the last order.

It can generate selective customer mailing lists, [DISPLAY ACCOUNT NAMES / ADDRESSES WITH SALES GREATER THAN $2,000 ANNUAL]. It will do mail merge for personalized form letters, provided you do the proper samples of FORMATS. Instead of "Attention Occupant", it will insert "Dear Larry" or "Dear Mr. Johnson", when it types the letter. It will generate mailing labels by extracting a multi-line address (usually 5) or keep track of product development information. [DISPLAY COMPONENTS FOR X-15] or [DISPLAY $ TOTAL FOR BILL OF MATERIAL ON X-15 SHOE SCRAPER]. It will keep corporate personnel records and give returns such as, [DISPLAY MACHINE OPERATORS IN DEPT. 101]. Some database programs will allow you to be sneaky and ask for something not really programed in. More than that, they will understand a short form request. Say, that the normal retirement age for your machine operators is 65 but you don't really have a specific field for retirement dates. You could get the information in short form like this, [DISP MACH OPS AGE 65 BY 311289]. The computer, if it has the right program, will quite correctly interpret it to mean you want a list of those machine operators that will be 65 by year end and up for retirement.


Some database programs will handle logic problems. LOGICAL is when the question can be answered with YES, NO or TRUE, FALSE. Questions like [IS THIS EMPLOYEE LEFT HANDED?] or [VALID DRIVERS LICENSE?]. This makes the database excellent for fast input and result gathering of multiple choice tests or examinations. You just input the Yes/No, True/False selections and the computer will give you a correct score count. (Plus do averages and bell curves if you feed it properly!)


A database will do accounting and payroll and keep track of bills payable or accounts receivable, [DISPLAY ALL PAYABLE ACCOUNTS DUE NEXT WEEK]. If you are heavy into accounting, financial tracking or playing the "What If" projection game, [WHAT HAPPENS TO OUR COMPANY IF SALES PROFITS GO UP 2% BUT THE UNION WANTS 9%?], then you should consider the SPREADSHEET. It is a database specifically geared to financial problems.


The secret to this ability to locate, select, display and print information is in the FIELDS you establish on the RECORD card entry of the database. It will handle information on practically anything you can type into HORIZONTAL ROW form or into VERTICAL HEADING templates. Horizontal is when the headings or FIELDS are laid across the top of a columned, accounting-type sheet. You tab across the ROW and fill in each box. Vertical headings are where the fields are repeated once for each card or RECORD on the screen and you go down the list typing in your responses.


The difference between having a good, smoothly working database that gives you the returns you want or one that is difficult to read and inconvenient to access or use with the Print Formats is in the advance planning you do and the experimentation you try. DON'T JUST DEPEND ON THE DOCUMENTATION. When you are setting up your database you should define the planning of the whole task under considerations of HOUSEKEEPING, PROCESS and END OF JOB.

HOUSEKEEPING is things like the design of the Fields. Are they the proper title length, have they been defined as Character, Numeric, Logic or Text? Am I exceeding my Record limitation of characters? Housekeeping and the ease of operation is what will keep the database growing. Design a sample run of 20 records and try some manipulations and format merges. You'll soon find out if your housekeeping is a good design you can live with.

PROCESS is the actual mechanical and electronic activity of selecting fields or tying the database to your formats. You have to know the limitations of what you can ask your program to handle or you may get the dreaded crash curse. Overload. Insufficient memory. Cannot access this file. Cannot read this file. The way you design the initial process can make a lot of difference on speed and ease of operation. This is where experience counts because the documentation rarely tells you what will cause the software to bomb.

END OF JOB is the real heart and justification of a database operation. When all is said and done, what is it to do? Establish what you want and what you expect the database to do for you. It is a tool. You are buying it and building a database to do something. What are the THREE MAIN items, your version of E.O.J., that are the end result you want? (If you have 640K instead of only 64K, then your identification list could be much longer than just 3 or 4 items.) Identification of this is critical before you start buying programs, let alone start designing the Record Fields or Formats.

There is no point in getting a database so sophisticated that you can't understand it or if it uses more memory than your computer has available. If you just want a program that will alphabetize your address book, then don't pay for a full blown database. Unless the features are of benefit to you, they are wasted money.

Let us assume you have established your E.O.J. and it justifies buying a database program. Regardless of what type of database you get, it will have limitations. Your mission is to use and get full advantage of what you pay for. You can only do that by research on brochures (Watch out! They lie or, at minimum, exaggerate) or you can check with fellow ADAM owners and finally you can beg, borrow or buy the program and try it. You need to learn things like Field Title and Input limitations, Record limitations, search and display characteristics and the merge capabilities. Most people get so concerned with the creation and input of the RAW database, they forget the importance of those outside formats (or Forms). A database without them is like a telephone book without a phone. Formats are the real user of your database. You've got all that information bottled up but the formats are the way you usefully apply that information for problem solving.


The problem most people have when they get a new database program is that they charge into their justifying project too soon. After doing input on hundreds of records, they discover they set up inadequate or inaccurate FIELDS or that they designated Primary Search Fields incorrectly or that the fields they established are just plain inconvenient for input. Some databases WILL NOT ALLOW FIELD CHANGES in mid process. You are either locked into the fields and formats you started with or you have to dump the whole operation and start over again. Now you know why I suggest the 20 record sample run to test HOUSEKEEPING. Nothing drives you crazier than the discovery, around record 500, that you blew it. You may want to display a NAME and PHONE number as primary fields, with the address and mail codes as secondaries. But most information sources will give it as NAME, ADDRESS, MAIL CODE and then PHONE. What you forgot is that you can usually call up just NAME and PHONE only, but it is a lot easier to input if it corresponds with your information source. Your layout might cause you a lot of back and forth time wasting that can be avoided by advance thinking or some short trial and error work. TAKE THE TIME TO LEARN IT FIRST!


In the course of my business experience I have worked with databases using the IBM format, the MacINTOSH format, COMMODORE and, our poor orphan, ADAM. On IBM I used a huge database on a System 36. The database was a custom design using RPG II language (Report Generator II). It was speedy and fully integrated but the most minute field change required an Act of Parliament and a week of high priced programmer time. I used an IBM XT clone with dBASE III+ running a custom personnel tracking package. It was a cracker. Fast, comprehensive and the total integration produced mailing labels, generated personalized form letters, tracked personnel by skills, tracked client companies with their own internal changes and maintained an auto-dial library of phone numbers for people who could provide information on any given subject. It would do everything except slice bread. But, it wasn't cheap! Just the programming cost $5,000 and required 640K, a 40 Meg Hard Drive and about 3 months to structure. On Mac (slow, but I love it!), I've used MicroSoft Filer and the database on Jazz. I found MicroSoft Filer, even on the people oriented Mac, to be difficult. It is advertised as capable of producing customized forms, even including pictures, plus sorting of every field. That's true. It will give an infinite variety of information manipulation but it has a complicated entry system and slow operation. The documentation is BAD! The database on Jazz, an integrated program for Mac that also includes a word processor, spreadsheet, communications and graphics (Lotus 1,2,3 for Mac), was less complicated but limited in size and information management. But Jazz worked well because it had much better documentation. The instructions actually seemed to have been written by a user, not some genius programmer.

All of those programs are definitely out of the ADAM league but I knew I had to have a database for home use. The process of finding a good database that would work on ADAM is where this article started and will conclude.

Back to Top