In the documentation it is clearly said:
Changing any part of an object name can break scripts and stored
procedures. We recommend you do not use this statement to rename
stored procedures, triggers, user-defined functions, or views;
instead, drop the object and re-create it with the new name.
What about renaming:
- primary keys
- unique keys
- foreign keys
- default constraints
- indexes
I am going to rename all of the above objects in order to match our internal naming conventions but I want to write an automatic script for doing this (as there are thousands of constraints).
The only issue I can think off is that if index is used with a hint
in statement it will be broken.
Could you tell any other reasons not to use the sp_rename
for such purpose?
Best Answer
sp_rename upates the name in sys.objects but it does not update the definition or objects referencing it.
When you run this query:
The
definition
column insql_modules
still containsTest
:When an object is rename, any object using it and referencing the old name will fail.
Here are a View and a Table beining renamed:
Again if you look at the definition, both the procedure and the view reference T1 (which does not exist anymore):
And both will fail with this error when you Select from it or Execute it:
You get the same error if you refresh the view:
All objects with references to the old name will break.
Before renaming an object (table, procedure, function, ...), you can look at its dependencies using
sys.sql_expression_dependencies
(MSDN) (deprecated:sys.sql_dependencies
MSDN,sys.sysdepends
(MSDN)