Re: Possible bug in SQL 'create or replace' wrt primary keys?

Hi, David:

I think you need to open a PMR to get an APAR created so IBM will fix this at 7.1 and above.

Meanwhile, further experiments seem to indicate that the problem is with the "or replace" logic.

So, a "circumvention" for now, until a PTF becomes available, is to issue:

ALTER TABLE yourlib/PK1 DROP PRIMARY KEY CASCADE

before re-issuing the new "create or replace table ..." when the "key sequence" has changed.

Hope this helps,

Mark S. Waterbury

> On 7/19/2017 11:58 AM, David Gibbs wrote:

Folks:

I observed some odd behavior and just want to confirm its a bug before we open a PMR.

We ran the following SQL statement ...

create or replace table yourlib/pk1 (f1 char (10), f2 char (10), f3 char (20), primary key (f1,f2));

and did a DSPFD on it ... the key fields for the file showed up correctly.

We then ran this statement ...

create or replace table yourlib/pk1 (f1 char (10), f2 char (10), f3 char (20), primary key (f2,f1));

(just reversing the order of the primary keys)

When we did a DSPFD on the file, the key fields for the file showed up as F1 & F2 (in that order).

Can someone run that same test and confirm the behavior?

Thanks!

david