Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!mordor!lll-lcc!well!mjr
From: mjr@well.UUCP
Newsgroups: comp.databases,comp.cog-eng
Subject: Re: Human Interfaces to Database Systems
Message-ID: <3970@well.UUCP>
Date: Thu, 17-Sep-87 20:06:36 EDT
Article-I.D.: well.3970
Posted: Thu Sep 17 20:06:36 1987
Date-Received: Sat, 19-Sep-87 15:55:56 EDT
References: <1275@geac.UUCP> <120@glenlivet.hci.hw.ac.uk>
Reply-To: mjr@well.UUCP (Matthew Rapaport)
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 15
Xref: utgpu comp.databases:448 comp.cog-eng:239

In article <120@glenlivet.hci.hw.ac.uk> gilbert@hci.hw.ac.uk (Gilbert Cockton) writes:
>
> Field validation by definition is
>application-dependent...

No it isn't!  In a fully functional RDBMS environment, field validation
is the function (ultimately) of the data dictionary!  The application
developer need only check the return values from an insert/update/delete
and determine which fields faild to pass muster.  I am doing that now
in a large project using Cincom's Supra DBMS.  This DBMS passes back
three levels of error messages.  The first tells you if everything
went ok or not.  The second tells you what the worst failure was (if
any), and the third enables the programmer to determine exactly which
field(s) failed their validity checks.  This is the way it should be
done...