PKs do not script correctly when renamed using sp_rename - by John Bell

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 612575 Comments
Status Closed Workarounds
Type Bug Repros 2
Opened 10/11/2010 10:44:16 AM
Access Restriction Public


If you create a PK without specifying the name, and then you rename it in SSMS or using sp_rename, subsequent scripting of the Primary Key or table does not include the name you have given it. The PK seems to have a status of 133665  in sysconstraints whereas a PK created by naming has a status of  2593
Sign in to post a comment.
Posted by Microsoft on 5/16/2011 at 9:38 AM
This has been fixed and will be available in the next release of SQL Server

Thanks for reportng it

Posted by Microsoft on 3/16/2011 at 4:39 PM
Thanks for reporting this. We have been able to repro it. We will fix it in a future release

Posted by DaveH0ward on 11/18/2010 at 2:32 PM
Here's my experience with this issue... When you rename a PK in SSMS object explorer, SSMS executes sp_rename passing 'INDEX' to the objtype parameter rather than 'OBJECT'. If 'INDEX' is passed to sp_rename, the is_system_named field in sys.key_constraints is not reset to 0; whereas if 'OBJECT' is passed, then is_system_named is reset. I believe this field is the reason the script is not being created correctly, and that the is_system_named field should be reset regardless if 'INDEX' or 'OBJECT' is passed.