RE: the idea of unique primary keys to be a solution thathasoutlived its usefulness?

[rob@xxxxxxxxx]

So, if the ADDPFCST will put one there, why not have one there in the 
first place and dispose of that extraneous logical file?

Rob Berendt
-- 
"They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety." 
Benjamin Franklin 




Brian Parkins <PARKIB@xxxxxxxxxx> 
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
11/18/2003 06:36 AM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
cc

Subject
RE: the idea of unique primary keys to be a solution    thathasoutlived 
its usefulness?










> If you do NOT put them on the physical you cannot add a referential
> constraint to this physical to another physical.  For example if I have 
a

> PF called CUSTMAST and a logical with CUSTMASTL1 and the unique key is
> only in CUSTMASTL1 then I cannot do a ADDPFCST on my order file to make
> sure that the customer number is on file.

 A (Parent) PF does not have to have a unique key defined to establish a
Referential Constraint.  If no key exists, the ADDPFCST comand will define
the Parent Key as a Primary Key automatically - i.e. adding a Key
Constraint to CUSTMAST.

Of course, it might be preferable to define a Unique or Primary Key
Constraint beforehand using ADDPFCST (or SQL).  DDS or SQL (Index)
definitions do not directly influence the Primary/Unique Key Constraint.

Brian Parkins

_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.