Re: Removing constraints

[Vernon Hamberg <vhamberg@xxxxxxxxxxx>]

I think maybe I'm confused - what DDS keyword establishes a primary key? 
AFAIK, the key of a PF is not the same thing as the primary key. For one 
thing, the primary key has to be unique and the key of a PF does not have 
that requirement. And in a DSPFD TYPE(*CST), the key of a PF will not be 
listed, unless you've used SQL DDL or ADDPFCST to add it. And in DSPFD 
TYPE(*ACCPTH), the PF key is listed with "Constraint type = NONE".

Vern

At 06:32 PM 4/2/2005, you wrote:
> Right. But primary key constraints, in a typical iSeries environment are
> actually specified in the DDS.
>
> If you are using SQL DDL and specify the primary keys as constraints,
> separate from the definition of the table, then, again, you can apply
> them from the DDL source. That's just a learned thing.
>
> I'm not implying that there isn't some other underlying problem with the
> save and restore, but, with full SQL DDL sources, you should be able to
> readily repair any constraint damage caused by the save restore, and
> only have to rely on the table data making it back.
>
> Managed DDL sources have everything ordered by drop, create table,
> create primary keys, create unique keys, create inversion keys, create
> foreign keys, create value constraints. They can then be applied by
> range, even in the CA SQL execution utilities.
>
> Question, did you ever resolve if the save was done with ACCPTH(*YES)?