Question

I have a database project which uses link servers in several of the views and stored procedures.

According to Microsoft, Visual Studio 2010 database projects do not explicitly support link servers, but you can kind of hack it using References and SQLCMD variables:
http://msdn.microsoft.com/en-us/library/bb386242.aspx

My database (the database itself) has a link server conenction to a Warehouse database. The Warehouse database project is stored in a separate Team Project Collection.

Is there any way to add the Warehouse project as a reference in my project?

Answer 1

The following article explains how to use reference variables in a database project.
http://msdn.microsoft.com/en-us/library/bb386242.aspx

This is necessary when you are referring to a database that is not in the same solution (see the first chart, second row).

In my case, I will probably have separate solutions for each different business environment (internal apps, external apps, warehouse, etc.). Each of these solutions will have several databases. But the databases will need to refer to databases that are not in the same solution (ex., an internal DB might have stored procedures that pull data from an external DB).

In this case, I think the best solution is to refer to the .dbschema file that is generated when the project is built. You can configure a nightly build for each project, and have the build output be copied to a specific shared drive location. You could then point any database project to any other database’s schema by adding a database reference (described in the above article) to the .dbschema ( on the shared drive) for the database.

If you wanted to make it more sophisticated, you could modify the build template to copy the necessary .dbschema files from the build output into each project and check them in.

In the case where the database does not have a project and is not being actively changed, it will be necessary to create a temporary database project for the database so you can build a .dbschema file. The built .dbschema file can then be checked in to the dependent project, and you won’t have to generate it ever again unless it changes.

I’ll do my best at an example…

Problem:
Project ABC depends on the data warehouse, and on project XYZ. Project XYZ is in source control under a different solution, but the Warehouse is not in source control.

Solution:

1. Create a nightly build for project XYZ
2. Configure the build output directory to go to a shared drive
3. Create a custom build template for project ABC that will copy the XYZ.dbschema file in to the ABC project and check it in
4. In project ABC, right-click on “Database References” and add a reference to XYZ, specifying the XYZ.dbschema file (instead of the XYZ database project, which is outside the solution)
5. Create the reference variables to the XYZ project (not sure this is necessary…)
6. Replace references to XYZ in stored procs & views with the reference variables you created in the previous step (not sure this is necessary…)
7. Now the references in ABC to XYZ should resolve.
8. Create a new database project (this can be a temporary, throw-away project)
9. Have it pull the definition from the Warehouse (right click the project and select “Import from database”)
10. Build the project
11. Copy the Warehouse.dbschema file from the build output into the ABC project
12. In project ABC, right-click on “Database References” and add a reference to the Warehouse.dbschema file
13. Create reference variables for the Warehouse
14. Replace references to the Warehouse with the reference variables
15. Now the references in ABC to the Warehouse should resolve.

I don’t know if it will work just like that, but that is the theory. Hope it helps…