Fully Qualify the Names of Database Objects
By fully qualifying all references to database objects, you can improve the design of your database code and make it easier for others to understand. You can also prevent errors when you copy code from one location to another, such as between database projects. For example, you might copy code from a stored procedure in one database that has a table named [Customer] in a schema named [CustomerData]. If you include the name of the schema in your references to that column, they become [CustomerData].[Customer]. By fully qualifying those references, you will be less likely to accidentally refer to a [Customer] table in a different schema if you copy that code.
Instead of fully qualifying each reference yourself, you can use database refactoring to automatically update the names of all objects in a block of code or throughout a database project. You can then preview each change before you apply it to your database project.
When you use refactoring, you update only your database project, instead of a production database. By following this strategy, you gain all the benefits of database projects, which include version control and team development. When you deploy your changes, the refactoring log file helps preserve the intent of your changes to the database project.
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 Starting Team Database Development.
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 use refactoring to fully qualify names of database objects, in addition to other types of refactoring, by following the walkthrough.
Fully qualify the names of database objects: You can use refactoring to fully-qualify the names of database objects in your database project. 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.