*
*LISTING 1
*
*Editing and validation of the current record by Warren Sirota
*
*This program allows the user to edit the current record in the
*database, and then checks that interest and type are valid.
*It will not accept the data until both fields are good.
*
done=.f.        && Setup for loop
do while .not. done
* Edit the record.
change next 1
if .not. bof()  && Have to step back
   skip -1      && to the record that was
                && just edited.
endif
**********************************************************************
*Check to see that the type and interest are valid.
*
*First we assume that nothing is OK.
typeOK = .f.
intOK = .f.
if type = 'MEMBER' .or. type ='VOLUNTEER' .or. type = 'PRESS';
   .or.type ='MANUFACTURER' .or. type = 'DEALER'
   typeOK = .t.
endif
if interest = 'DATABASE' .or. interest = 'COMMUNICATIONS' .or.;
   ONE-PERSON BUSINESS'
   intOK = .t.
endif
if .not. typeOK
   ans = ' '
   @ 18,5
   ?'The type that you entered is invalid.'
endif
if .not. intOK
   @ 19,5
   ?'The interest that you entered is invalid.'
endif
*The whole screen is OK only if both type and interest are OK.
ok = typeOK .and. intOK
if .not. ok
    wait
else
    done = .t.
endif
**********************************************************************
enddo   &&maim loop
Full-Scale Validation
    The Problems are much more extensive when trying to set up a
menu-driven system which allows on-the-fly changing of the validation
conditions by the user. in our example, two additional databases would
have to be set up, one for allowable TYPES and one for allowable
INTERESTS. Each of these databases would need three routines written for
it (Add, Change, and Delete). The Change and Delete routines would each
have to look through the contacts database to see whether the changes
would cause any existing CONTACTS to have invalid entries under the new
rules, and they would have to take appropriate action (like not allowing
the changes) if such entries were discovered. Also a static display of
the available TYPE and INTERESTS would no longer suffice. Instead,
routines would have to be written which would list all available choices.
These routines would have to take screen formatting carefully into
account, because there would be no way of knowing in advance exactly how
many TYPES and INTERESTS would have to fit on a screen. In fact, you
would have to write your own multi-page listing and choice facility.
   Another tricky validation issue is duplicate checking. When you have a
large mailing list, say several thousand people, the odds are good that
you will have several individuals with identical first and last names.
It's very important that, before allowing anyone to change any data, you
display some kind of unique information about this people. Social
Security number is best, but you may not have that available. Addresses
can work in many situations. The program then should insist on some sort
of confirmation ("Is this the right John Smith?"). If confirmation is
not forthcoming, the program needs to find all other John Smiths in the
database(and also all J. Smiths, etc.) and ask for a confirmation. If
the database is very large, the program may need to accept further
qualifying data to limit this process (the initial prompt could be
"Enter Last Name, First Name, and State", for instance). Only upon
finding that none of the John Smiths in the database is the right one
should the program allow the creation of a record for yet another John
Smith.
    So you see, the simple database mailing list, ostensibly the easiest
task in the world for a database manager, can quickly evolve into a
major task once you require consistency of data entry. It's a shame that
most of our data management tools aren't better designed to address this
all-too-common problem.
"
--- TMail v1.31.5
---------------