Re: Constraints, anyone?

Charles Wilt wrote:

Primarily because the constraint term comes from the SQL world.
In fact, if you defined a table using SQL DDL and give it a
primary key constraint, you'll get what looks like a regular
uniquely keyed physical *FILE object on the i.

There is one difference, a DDS uniquely keyed physical file or a
file with a unique key constraint allows NULLable fields as part
of the key. So you could have multiple records with the same
NULL key value.

Whereas fields that are part of a primary key constraint must
also be defined NOT NULL.

Although the database null value is not allowed, the attribute of the column [field] itself need not be defined with NOT NULL. As part of a primary key constraint, either implicitly or explicitly, the column can have a CHECK constraint which prohibits the database null value; i.e. column IS NOT NULL. For example, the following column named "D" which is effectively ALWNUL gets an implicit check constraint defined to ensure that there will be no null values, such that the column can be defined as the primary key constraint:

create table pkd
( d int
, primary key (d)
)

The constraint can even be removed to leave just an access path. The following does so to the above SQL TABLE. Since a TABLE is not really ever supposed to be /keyed/, I am not sure about the actual support for doing so; though I have documented similarly in the past, the remove constraint CL command as a method to effect a unique keyed TABLE:

DSPFD PKD *CST
DSPFD PKD *ACCPTH
RMVPFCST FILE(PKD) CST(*all) TYPE(*PRIKEY) RMVCST(*RESTRICT)
DSPFD PKD *CST /* Reply 'K' to keep *AccPth */
/* like with implicit adding, chkcst implicitly goes too */
DSPFD PKD *ACCPTH

Regards, Chuck