Re: Constraints, anyone?

I've been reading the stuff you've referred me to, and I was delighted to find that constraints go back at least to V4R2, which is further back than we have any need for them to go.

The subject of referential constraints brought a question to my mind, something that may push the limits of what's possible, or it may exceed those limits:

(And keep in mind that I am NOT using the SQL sense of the word "table" here!)

Suppose I have a "reference table" file, FOOREF, that is keyed:
PRITBLNUM (primary table number)
PRITBLENT (primary table entry)
SECTBLNUM (secondary table number)
SECTBLENT (secondary table entry)

containing a number of reference tables, some of which contain second-level reference tables. For example, "Address types" would be table "ADT", and "mailing address" would be entry "M" of table "ADT."

Now suppose we have an address file, FOOADDR, with an "Address type" field in it, which should contain a valid address type listed in the ADT table of FOOREF.

A referential constraint that would enforce a requirement that the "Address type" value match a value in Table ADT of FOOREF would obviously have to hold PRITBLNUM constant, match it to PRITBLENT (despite the two fields being of different lengths), and treat SECTBLNUM and SECTBLENT as "don't care" terms.

Can that be done as a constraint?

--
JHHL