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.


6
0
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

Description

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 Sunil [MSFT] 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

Sunil
Posted by Sunil [MSFT] 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

Thanks
Sunil
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.