cancel
Showing results for 
Search instead for 
Did you mean: 

Who's playing with constraints ?

Former Member
0 Kudos

Hi

I went through a strange behavior on a solution Mger system I would like to share.

Maybe someone has the complete solution...

I went through a painful SP stack import on a solman system, i did get some block corruptions and had to export tables.

When importing the tables I found that primary index could not be rebuilt for table SEOCOMPODF(Definition class/interface component)

because of unique constraint violation :

Processing object type TABLE_EXPORT/TABLE/INDEX/INDEX
ORA-39083: Object type INDEX failed to create with error:
ORA-01452: cannot CREATE UNIQUE INDEX; duplicate keys found
Failing sql is:
CREATE UNIQUE INDEX "SAPSR3"."SEOCOMPODF~0" ON "SAPSR3"."SEOCOMPODF" ("CLSNAME", "CMPNAME", "VERSION")

I did check and found that the table has many duplicates

SELECT  CLSNAME || CMPNAME || VERSION, COUNT(CLSNAME || CMPNAME || VERSION) AS dup_count
FROM  sapsr3.SEOCOMPODF
GROUP BY CLSNAME || CMPNAME || VERSION
HAVING     (COUNT(CLSNAME || CMPNAME || VERSION) > 1);

*189 rows selected.*

I did then check on some other solman systems and found that they all have duplicate keys (less than 192 but all at least 4 or 5).

I'm wondering what did create these duplicates.

My only guess was that maybe R3trans was disabling constraints when importing data...

Anybody has a clue ?

Accepted Solutions (0)

Answers (1)

Answers (1)

thiago_cavalheiro
Active Participant
0 Kudos

Hello,

SAP does not create PRIMARY KEY at the database level, it creates only a UNIQUE index. So it might have been caused due to the index having become invalid, with that the duplicated rows should have been created during application regular run. R3load does not create new data, so the duplicates could not have been originated by it.

Regards,

Thiago