In 13.2.0.258, a script generated for a table that has a PK with a different name than its supporting index does not generate the index with the correct name. In my case, it's important as the ERP system (JDEdwards) that creates all database objects refers to them by specific names. I can supply a case in a few hours, but wanted to get this out here before I forgot...
CREATE TABLE MY_TABLE
(
MY_COL NUMBER,
MY_DATA NCHAR(2)
)
TABLESPACE USERS;
CREATE UNIQUE INDEX MY_INDEX ON MY_TABLE
(MY_COL)
TABLESPACE USERS;
ALTER TABLE MY_TABLE ADD (
CONSTRAINT MY_PK
PRIMARY KEY
(MY_COL)
USING INDEX MY_INDEX
ENABLE VALIDATE);
And here's the result I get from the RHS script tab in the SB:
CREATE TABLE MY_TABLE
(
MY_COL NUMBER,
MY_DATA NCHAR(2)
)
TABLESPACE USERS
NOCACHE
RESULT_CACHE (MODE DEFAULT)
/
-- There is no statement for index MY_INDEX.
-- The object is created when the parent object is created.
ALTER TABLE MY_TABLE ADD (
CONSTRAINT MY_PK
PRIMARY KEY
(MY_COL)
USING INDEX
TABLESPACE USERS
ENABLE VALIDATE)
/
-- There is no statement for index MY_INDEX.
-- The object is created when the parent object is created.
In this case, the index needs to be named "MY_INDEX", but the script will create one called "MY_PK" instead.
huh, weird, that's basically the same that I did but with a different result. I wonder if there is something about DB that's doing something different in data dictionary.
12.1.0.2 The XML behind DBMS_METADATA did change between 11.2 and 12.1. There's a bug 20217704 to fix at least one of the anomalies, but I decided not to install it...
Doh! I saw that and had changed it, but it made no difference. I didn't record my steps, but after taking a look at it again, I think a refresh of the RHS may have been needed post-change.