Reptools command import fails on DB with SqlIntegrityConstraintViolationException
I've exported the ETM database out of MS SQL server using ELM repotool command >repotools -export and then I want to import the content into IBM DB2. The import process failed with the following exception.
CREATE UNIQUE INDEX GCSDK.DBTRSMDCNTRBTNTRC0 ON GCSDK.DB_TRS_MODE_CONTRIBUTION_TREE(CONFIGURATION_URI) com.ibm.db2.jcc.am.SqlIntegrityConstraintViolationException: DB2 SQL Error: SQLCODE=-603, SQLSTATE=23515, SQLERRMC=null, DRIVER=4.26.14 at com.ibm.db2.jcc.am.b7.a(b7.java:806) at com.ibm.db2.jcc.am.b7.a(b7.java:66) at com.ibm.db2.jcc.am.b7.a(b7.java:140) at com.ibm.db2.jcc.am.k4.b(k4.java:2471)
Do you have any idea what we could do to address this exception? |
One answer
The DBTrsModeContributionTree table is a cache of contribution trees that was introduced in 7.0 RC2 (release candidate) onwards. It requires that the configuration URI is unique. That uniqueness constraint was there from the outset, so I'm puzzled as to how the data in the source SQL database can have such duplicate configuration URIs.
For now, I suggest we clear that contribution cache in 7.0.2 on SQL before the export. Since this is happening on the ETM container, you can clear the cache by using a web browser on
<qmContextRoot>/gcsdk/diagnostics
clicking on the ClearConfiguration Cache button.
That should clear that table. Then export from ETM out of MS SQL server and retry the import into DB2.
The only downside of clearing that cache is that the first time users access a particular GC from ETM, it may take longer to initialize the context because the contribution data for that GC will not be in the cache and will have to be fetched. Over time, the cache will get repopulated with data for the GCs that ETM users access. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.