Re: Removing constraints

[R Bruce Hoffman <bruce.hoffman@xxxxxxxxxxxxxxxxx>]

True. I may not have been precise enough in my language there. My fault.

Generally in dealing with iSeries shops, when they say primary key, they
aren't usually refering to a "real" SQL DDL primary key constraint, but
either a logical file's or the physical file's key specification that
they consider to be primary.

No matter. What I was getting at was is this a mixed DDS and SQL DDL
schema/library or completely SQL DDL schema?

In the case of the former, I know that unique keys in physical files are
"consumed" by the process of adding a primary key constraint to the file
if that access path can provide the constraint. What I don't recall is
the "sharing" of access paths if the so called "primary key" is actually
in a logical file when the DDL primary key constraint is applied. (Is it
shared or not?)

And in the case of the completely SQL DDL schema... is it managed by a
tool or at least by a member/file of DDL statements?

Now, as I read back... I dunno... maybe I'm still confusing? <VBG>


On Sat, 2005-04-02 at 22:37, Vernon Hamberg wrote:
> 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)?
-- 
"Bigamy is having one wife too many. Monogamy is the same."
-- Oscar Wilde