none
Cannot attach a restored collection that was not properly detached first

    Question

  • I have read this post: http://social.msdn.microsoft.com/Forums/en-US/tfsadmin/thread/04bb28c7-7382-493e-b1c6-601470b9229c -- I have done all of the steps recommended on-line and those steps have been verified and repeated with support to no avail. Luckily I did have 2 TFS instances, so a Sandbo to play in.  What I did was:

    • detach the original collection in Production
    • restore the backed up collection to Sandbox
    • Used Recover and Attach commands to get collection restored and working in Sandbox (worked great!)
    • Detached the collection from Sandbox
    • Backup and restore operation to move collection to production
    • Attempt to Attach the collection to production <insert sad trombone here>

    The attach failed with the following error:

    “[2012-10-09 16:34:43Z][Error] Cannot insert duplicate key row in object 'dbo.tbl_IdentityMap' with unique index 'ix_IdentityMap_masterId'.

    SQLCLUSTER1.Tfs_UL-Oracle-R12..prc_UpdateIdentityMap: Unexpected Database Failure - %error="2601";% executing INSERT statement for tbl_IdentityMap

    The statement has been terminated.”

    Anyone else ever seen this? Know what the heck that error is referring to? It's making me lose sanity points here! I'd also love to know why this happenned.  Maybe it is because of the Recover? But that wouldn't explain the duplicate on production since no Recover was done there. Is it possible I detached but some trace of it was still there?


    Angela Dugan

    Tuesday, October 09, 2012 11:56 PM

Answers

  • Turned out there was a bug in TFS 2010, and the product team was able to send me a patch to fix it which updated a stored procedure used by the Attach command.  Not sure if this is going to end up out on MSDN, but it was a lifesaver.  Another hiccup for us was that we had tried to attach the collection and it failed, so the patch from the product team did not work the first time.  We were not sure if the issue was a duplicate name problem, or if the database was corrupted by the failed attach.

    We went back to the detached database on Sandbox, restored it to Production again with a new name, and then when we ran the Attach using the new stored procedure it worked!!


    Angela Dugan

    Thursday, October 11, 2012 4:48 PM

All replies

  • Hi Angela, 

    Thanks for your post.

    If you want only move your Collections from A Server to B Server, and the A Server still working, please refer to the following steps:

    1        On A Server, launch TFS Admin Console>>under Team Project Collections tab, Detach the collection. Detach process is essential and should happen successful.

    2        Backup the Detached database(the collection database on your A Server).

    3        Restore the database to the B Server’s SQL instance.(After restored successfully, ensure the collection database displayed in B Server’s SQL instance correctly)

    4        On B Server, launch the TFS Admin Console>>under Team Project Collections tab, Attach the collection. 

    Please refer to this similar post: http://social.msdn.microsoft.com/Forums/en-GB/tfssetup/thread/1497dc50-1cf8-4bfb-af11-e3a9f7e3b936.   


    John Qiao [MSFT]
    MSDN Community Support | Feedback to us

    Thursday, October 11, 2012 2:21 AM
    Moderator
  • That's not what I am trying to do, I am aware of how to move a collection.  I am trying to replace a collection with a backup of that collection from the night before, but the backup is not a detached database, it was a full SQl backup.

    Angela Dugan

    Thursday, October 11, 2012 1:36 PM
  • Turned out there was a bug in TFS 2010, and the product team was able to send me a patch to fix it which updated a stored procedure used by the Attach command.  Not sure if this is going to end up out on MSDN, but it was a lifesaver.  Another hiccup for us was that we had tried to attach the collection and it failed, so the patch from the product team did not work the first time.  We were not sure if the issue was a duplicate name problem, or if the database was corrupted by the failed attach.

    We went back to the detached database on Sandbox, restored it to Production again with a new name, and then when we ran the Attach using the new stored procedure it worked!!


    Angela Dugan

    Thursday, October 11, 2012 4:48 PM
  • Hi,

    Do you know where I can get thit patch? Or do you have a fil name, so I may find it somewhere?

    Thanks

    Lasse 

    Saturday, March 23, 2013 4:51 PM
  • I got this patch by engaging MSDN support and they got me in contact with the TFS product team directly.  I believe they said this fix was rolled into TFS 2012 Update 2 though...  And that is go-live now.

    Angela Dugan

    Friday, March 29, 2013 4:57 PM