From the May 1986 Microtimes - Validating Data by Warren Sirota
"
        The Insidious Misspelling Problem
  Suppose that you've somehow been conned into organizing the mailing
list for your local computer user' group. In a users' group, you have
contact with all sorts of people : members, volunteers, press,
manufacturers, and dealers among them. Also, many of these individuals
have particular interests which are worth tracking (for the purpose of
forming Special Interest Groups, if nothing else). These interests might
include database software, communications, one-person business, etc.
  So, you go ahead and define your database structure, set up a custom
data-entry form if you'd like to, and convince some volunteers to enter
some data for you. The system works fine, it seems to run itself, the
volunteers aren't complaining much, and eventually you have a few
hundred contacts in the database.
  When the time comes to mail news of a special club offer to all the
members. you try to print labels for all the people in the database who
have the word "MEMBER" entered in the field called TYPE. In XBASE, this
would be done with the command:
LABEL FORM MAILLIST FOR TYPE = "MEMBER"
  The labels are printed out and sent out. A week later, you get calls
from half a dozen members wondering why their friends got notices but
they didn't. When you look in the database for these individuals, you
can see that they're in the database. Closer examination reveals that
one of them has been entered with type "MRMBER" one with "MENABOO" and
four or five with "MBR" or just "M".
  The biggest problem with this type of error is that it can easily go
undetected. A few spelling mistakes, which result in a few labels going
unprinted, will rarely be detected. Admittedly in our example the
consequences were minor. However if you had to handle half a dozen
more-or-less irate phone calls, you might feel differently about that.
        Solutions
  The "low-tech solution to the misspelling problem is to just print out
a list of what's been entered into the database and to check it by eye.
This can be made easier by printing the suspect information in sorted
order. Anomalies will then be fairly obvious to the eye. For instance,
in XBASE, this command sequence would be helpful for spotting invalid
INTEREST entries:
INDEX ON INTEREST TO INTEREST
LIST LN, INTEREST TO PRINT
  Another way of spotting errors after the fact would be to use a
programming statement to print out all last names where interest did not
have a permitted value.
  Still, it's better to catch trouble before it starts. If it were
possible to specify a range of permissible value for TYPE and INTEREST
in the database definition for CONTACTS , and to have the database
management software treat those conditions just as it now treats the
difference between numerical values and alphabetic, then a great
increase in utility would be realized without much of an increase in
complication. Of course, if you ever wanted to change the list, there
could be some problems. It's easy to add a new permitted type to the
ones that are already there, but not as simple to remove a type from the
allowable list. What do you do with the data that have already been
entered, in that case?
  At any rate, since most database systems don't provide this type of
extended validation, I'll propose a couple of methods of dealing with it
using XBASE. The easiest method is to "hard-code" the validation. This
means that you write a data-entry routine which gets all the values from
the user and checks that things are OK. Listing 1 contains an example of
such a routine.
  The only problem with the hard-coding method is that, in order to
change the validation, someone has to put their miner's helmet on and go
in and change the actual code. The changes that are required are minor,
however - just extending the conditions for type or interest - and are
within the capabilities of many users. Two precautions should be used
when doing this. The fist is to make a backup copy of the program code
before changing it, and the second is to only add permitted values, and
never to delete or change existing permitted values. These operations
generally require the intervention of a programmer or a sophisticated
user.
  Also, it should be noted that, in order to conform with changes to the
validation code, changes also need to be made to the screen prompting so
that all the allowable values are listed. In XBASE, this can be done
with the MODIFY SCREEN command.
"
--- TMail v1.31.5
---------------