Overview of Rename Refactoring
You can use database refactoring to rename a schema object. Other objects that reference the renamed object are automatically updated with the new name. For example, you can rename a column in a table, and any stored procedures that reference that column are automatically updated with the new name. Examples of schema objects that you can rename are as follows:
Columns in tables, views, and functions
Stored procedure parameters
Traditionally, renaming database objects has been easy, but updating the objects that reference that renamed object has been difficult. Updating the referencing objects has been a manual task that required having a record of all objects that reference the renamed object or that relied on sp_depends to get that information. Because sp_depends might not always return the expected data, it was sometimes not possible to get that information reliably. By using database refactoring, you can rename database objects and their referencing objects reliably. By default, updates are applied only to objects whose definitions cause no warnings or errors.
In addition to automatically updating referencing schema objects, database refactoring can also update data generation plans, scripts, and unit tests. For more information, see Considerations before Renaming Database Objects.
When you rename a database object, the .sql file associated with that object is not renamed. You can rename the file manually by using the Solution Explorer window.
Additional Uses of Rename Refactoring
Rename refactoring can also help you perform the following common tasks:
In a case-insensitive environment, you can change the case of a schema object name and all its references to match the casing conventions for your organization. For example, if your database project has a mix of references to "Myid" and "MyID", you can use rename refactoring to change all references to "MyID".
References that were already the correct case are updated (to the same value). If the file that contains those references is under version control, it is checked out as part of the refactoring operation.
Rename two or more objects so that their names and references match. For example, you can merge two schema names (such as "Person" and "Person Name") or two names that differ only by case in a case-sensitive environment (such as "MyID" and "Myid").
Add square brackets around a schema object name and all its references to follow best practices for object naming. For example, you can replace all references to "MyID" with "[MyID]".
References that already were enclosed in square brackets are updated (to the same value). If the file that contains those references is under version-control, it is checked out as part of the refactoring operation.
When you perform these tasks, an error message warns you that the schema object that has the new name already exists. You must click Yes to make the change. However, you can preview and selectively exclude individual changes if, in the Rename dialog box, you left the Preview changes check box selected.
Database refactoring is database project based. This approach means that you do not make changes directly to a live database, but to the database project instead. By following this strategy, you gain all the benefits of database projects, including source control and team development. You can then deploy changes that were made to the database project by using the database project deployment feature. For more information, see Building and Deploying Database Schemas.
In a team environment, you should run application and database unit tests before you deploy your changes to a production server. For more information, see An Overview of Database Creation and Deployment in a Team Environment.
The Preview Changes Dialog Box
When you use refactoring to rename a database object, you can preview the changes. By using this option, you can see changes that will be made to all of the objects that reference the object that you are renaming.
The Preview Changes dialog box contains an upper pane and a lower pane. The upper pane contains a tree that lists the objects that will be changed, and the lower pane shows the script that will be generated to make the changes. When you click an object, the upper pane displays the old name, and the lower pane displays the new name. For more information, see How to: Preview Renaming Changes.
Replacing References to Servers and Databases
In object definitions or scripts, you can include references to objects in other databases if you specify the names of the databases that contain the objects to which you are referring. If references and the objects are on different servers, the references must also specify the names of the servers for the objects to which you are referring. You can specify databases and servers by name or by variable. After you create these references, you can use refactoring to update them if you must later specify a different name, replace a name with a variable, replace a variable with a name, or replace a variable with another variable. For more information about cross-database references, see Overview of Cross-Database References. For more information about how to rename these references, see How to: Rename References to a Server or Database.