Re: Removing constraints -- MIDRANGE-L

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)?

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.