Check constraints was: Imbedded SQL vs Sequence object

Then, Joe, why should one have external fields? After all, if one is
going to check if an area of the record is numeric or alphanumeric in the
edit program why do it in the database? (Let alone the fact the DDS is a
sick joke and allows you to store characters in numeric fields versus
DDL.)

I know that you came from SSA, and not only did they not use primary keys
on their physical's, but they didn't even specify UNIQUE on their logical
files and, unless you restricted everything to their edits, it was quite
easy to have duplicate keys in the item master. Well, conversion
programs, etc, do not fit nicely into their edits.

And, as much as some people push externalizing database access so that all
access to the database is from getter and setter routines it rarely is
ever used. And I suspect that the people who push that the most would
scream bloody murder if the restriction included themselves and not just
their coworkers and the users of their application. (Even though I used
this 20+years ago on an application written on a WANG 2200 called TOM for
The Office Manager. And never once bothered to learn how Wang Basic
accessed the files directly.)

Logical cut off point? My opinion that would be whatever couldn't be done
within the database. And, I might even suggest a before trigger as a
final dam to catch those that couldn't be done with check constraints or
referential constraints.


Rob Berendt