Warnings, Warnings Everywhere: Database References in Visual Studio 2010

by Jonathan on June 11, 2010

Visual Studio 2010 Logo

In previous articles we discussed how database professionals could use the features in Visual Studio 2010. During the video I demonstrated with a test project. Since then I have been working to migrate my DBA database project into Visual Studio 2010. From the beginning I ran into issues. This was a very discouraging start to using Visual Studio 2010 for my projects. There was a very simple fix and now we are moving right along.

One of the scripts that I deploy to all of my servers is Adam Machanic’s (Blog|Twitter) WhoIsActive. I created a stored procedure and saved the script. A few seconds later I saw 84 warnings show up on the Error List. Something was amiss. I have this script deployed into most of my environment and it works like a charm. It was time to do a little research.

The warnings all seemed to be due to some sort of missing reference. The WhoIsActive script, like many DBA scripts, uses the [master] database heavily. Visual Studio is parsing through the script and can’t find any of the items that the script is trying to reference, so it throws a warning. The good news is that there is a very simple fix.

Adding a Reference to master.dbschema

Database projects are designed to be self contained. When creating a database project, scripts typically will reference items within the same project. Some scripts, however, will reference other database items. In this case, the [master] database is referenced. The master.dbschema file is not included in every project for performance reasons. It contains a large number of objects that are unnecessary for many projects.

The default installation of Visual Studio 2010 includes dbschema for both the [master] and [msdb] databases. There are separate schema SQL Server 2005 and 2008. These files are located in the Visual Studio installation directory in the Extensions folder. I am working on a SQL 2008 project so I will use the following folder:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\VSTSDB\Extensions\SqlServer\2008\DBSchemas

To add the database reference right click on the References folder in the Solutions Explorer and select Add Database Reference. This will open the Add Database Reference window. Add the master.dbschema by selecting browse and navigating to the folder that contains the appropriate schema for your project. In my case, it was the folder listed above. I accepted the defaults and clicked OK. Saving the project will cause Visual Studio to parse the code again and resolve the reference errors.

Solution Explorer

If no other references have been added, it can also be added from the References tab of the Project Properties page. If the project already contains references this tab will show a list of the current references and no additional references can be added.

We are working up more articles and videos about Visual Studio 2010 and its features for Database professionals. Do you have a specific topic you would like us to cover? We would love to hear from you.

  • Peter

    We’ve hit that one, too. References can help, but the fun part comes when you have a set of DB’s that reference each other (we have six). If you have that scenario, not only do you get all sorts of fun warnings when the case of the DB doesn’t match the alias defined, but your deploy time goes up seemingly exponentially. 30-45 minutes to deploy 6 NEW databases is just way too long.

    However, to answer your question, I would really love to hear how we should handle branching 6 interdependent databases when you have multiple projects that hit those same databases – all with their own branches.

    In addition, I’d love to hear a good branching strategy for data. Often we have release-specific data changes. They need to go with a specific release and not before/after.

    • http://www.jonathanagardner.com Jonathan Gardner

      Peter, I don’t have an answer for you on that one. I agree that 30-45 min is way to long to deploy new databases.

      The more research and use I put into source control I can see that we may have multiple posts on that topic. I will work one up specifically on branching and see if we can help out with you situation. Look for that in the very near future.

  • Peter

    We’ve hit that one, too. References can help, but the fun part comes when you have a set of DB’s that reference each other (we have six). If you have that scenario, not only do you get all sorts of fun warnings when the case of the DB doesn’t match the alias defined, but your deploy time goes up seemingly exponentially. 30-45 minutes to deploy 6 NEW databases is just way too long.

    However, to answer your question, I would really love to hear how we should handle branching 6 interdependent databases when you have multiple projects that hit those same databases – all with their own branches.

    In addition, I’d love to hear a good branching strategy for data. Often we have release-specific data changes. They need to go with a specific release and not before/after.

    • http://www.jonathanagardner.com Jonathan

      Peter, I don’t have an answer for you on that one. I agree that 30-45 min is way to long to deploy new databases.

      The more research and use I put into source control I can see that we may have multiple posts on that topic. I will work one up specifically on branching and see if we can help out with you situation. Look for that in the very near future.

Previous post:

Next post: