Re: Constraints, anyone?

[CRPence <CRPbottle@xxxxxxxxx>]

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