Re: Removing constraints

[Vernon Hamberg <vhamberg@xxxxxxxxxxx>]

Just tried that experiment with using the LF key as primary. Turned out 
that the PF became the owner of the access path, which surprised me a 
little. Before the ability to CHGPF based on a source member, it would not 
even have been possible to add keys to a PF without deleting the dependent 
LFs first.

Later
Vern

At 09:40 AM 4/3/2005, you wrote:
> That's what I thought - we on the S/38-i5 have often used "primary key", 
> if we've used the term at all, to mean the key of the PF. As we've been 
> saying, this is not the "official" meaning in relational discussions. BTW, 
> my apologies if this seems too theoretical - I'll be done soon.
>
> The question of shared access paths is not theoretical - the space and 
> performance implications are important. I saw the "consumption" process 
> when I added a primary key constraint on the PF with a key. Then I tried 
> taking it off. Other than the fact that it took forever for the system to 
> bring up the CPA32B1 message, I was intrigued that it gave me the choice 
> of removing the key completely or keeping (restoring) the original key.
>
> I'd not thought of the primary key coming from a logical with unique key. 
> Interesting. And, since sharing is dependent on the order of creating the 
> keys, a few experiments would be interesting. When I have some time.   ;-)
>
> Thanks
> Vern
>
> At 07:17 AM 4/3/2005, you wrote:
> > 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.