Given the PF has only one member and MAXMBRS(1), then that script effects the *removal* of the Keyed Access Path, thus reverting the PF to an Arrival Access Path. That is entirely different than removing the /unique/ requirement [avoiding the word "constraint", because the unique access path is not a CONSTRAINT] from the existing access path. And the DDS source member no longer matches the actual PF, and the remaining PF will not show create-from-source information that matches the updated DDS... if in fact the DDS gets updated to reflect that change.

Regards, Chuck

On 02 May 2013 08:21, rob@xxxxxxxxx wrote:
You mean like this:
UNIQUE
R ABR
MYKEY 11A
MYDATA 10A
K MYKEY

INSERT INTO ROB/AB VALUES(1, 1)
1 rows inserted in AB in ROB.
INSERT INTO ROB/AB VALUES(1, 1)
Duplicate key value specified.

ALTER TABLE ROB/AB DROP PRIMARY KEY RESTRICT
Table AB in ROB does not have a primary or unique key.

ALTER TABLE ROB/AB ADD PRIMARY KEY (MYKEY)
ALTER completed for table AB in ROB.

ALTER TABLE ROB/AB DROP PRIMARY KEY RESTRICT
ALTER completed for table AB in ROB.

INSERT INTO ROB/AB VALUES(1, 1)
1 rows inserted in AB in ROB.

Summary: Yes. Even though it already has a primary key ADD the
constraint with SQL and then delete the constraint with SQL and it
drops the primary key.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2026 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.