This content has been marked as final. Show 2 replies
Hi Tyson,1 person found this helpful
The creation of a workspace does not update any _LT tables. It only creates the version/workspace within the hierarchy of the existing workspaces. The operation will acquire a lock on the parent workspace, which can be affected by dmls on other tables, but no data is ever modified.
Is there an existing trigger that populates the primary key columns when they are null? The problem with this being the root cause of what you are seeing, is that the triggers are only fired when going through the view. They are not defined on LT, which is the table that Workspace Manager typically uses for our internal operations. They are removed from the physical table by the enableversioning process. There are exceptions to the internal dmls always being done on LT, but they're are not too many.
After looking at the other topic you mentioned, are you sure that there wasn't a delete of the original row and an insert of a new row with a distinct primary key value? Aside from that, not sure how what you are describing can happen, but would be glad to take a closer look if you can reproduce it.
Ok so there was a bug in the application. It does not explicitly go to the latest savepoint when creating a new transaction workspace. If the user navigates the application just right they can view an old transaction, which would set the savepoint, and then navigate to the screen where they create the new transaction. In this case the records were added as part of a later transaction and were not in the parent savepoint for this transaction. The user added that information again as part of this transaction and that is why the merge is blowing up on the unique constraint.
I don't know if i explained that in manner that anyone can follow; but long story short it is 100% our problem.
Thanks for your time and info
Edited by: Tyson Jouglet on Jun 19, 2012 3:37 PM