Rename References to a Server or Database
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 Using References in Database Projects. For more information about how to rename these references, see How to: Rename References to a Server or Database.
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 Build and Deploy Databases to an Isolated Development Environment.
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 Verifying Database Code by Using Unit Tests
In the following table, you can find descriptions of common tasks that support this scenario and links to more information about how you can successfully complete those tasks.
Get hands-on experience: You can become familiar with how to rename references to a server or database, in addition to other types of refactoring, by following the walkthrough.
Rename all references to a server or database: You can use refactoring to automatically update the names of servers, databases, or SETVAR variables in cross-database references. As part of the refactoring operation, you can preview the changes before you apply them.
Undo a refactoring operation: If you decide that a refactoring operation needs to be reversed, you can undo that refactoring operation in the current session of Visual Studio.
Deploy database refactoring changes: After you refactor the database project, you must deploy those changes to a target database. Typically you will deploy your changes to your isolated development environment to test them before you check them in to version control.
Troubleshoot problems: You can learn more about how to troubleshoot common problems with database refactoring.