This content has been marked as final. Show 3 replies
Hi Tyson,1 person found this helpful
Are you sure there are no other rows that have a conflicting value for the unique constraint? What you have described should work. Since the rows have been deleted, they are no longer considered when evaluating the constraints when executing RefreshTable. You should be able to both merge and refresh the workspace after deleting the rows. Also, the row(s) with the 'D' wm_optype would not have a retiretime value, unless the row was reinserted. Only the 'I' or 'U' row(s) would have a retiretime value in this case.
If there are not any other rows, then I would need a more complete description. Are there any continuously refreshed workspaces that have T-520575 as a parent workspace? Those workspaces would also have to be checked.
if you are sure, that none of the already mentioned possible reasons applies for your case you may wanna check, whether you're affected by Bug #12730297. we also had the case that a UC violation was raised although we were refreshing the deletion of objects.1 person found this helpful
in our case we were running on oracle 10g, but IIRC the bug also was present in 11g (ben? :-))
That bug could potentially be the reason for the unique constraint violation as it affects versions up to 22.214.171.124. However, I cannot say for sure without more details. Essentially, the without the fix for the bug, Workspace Manager checks the entire workspace for unique constrqaint violations, not just the rows being refreshed as specified by the where clause.