How to avoid broken references in a Visual Studio database project?

Question

We've recently moved one of our SQL Server projects to a Visual Studio database project, but I think something is wrong as it will not fail to build if a stored proc references invalid tables, table aliases or columns. It only fails if the syntax itself is incorrect.

For example, the following example happily compiles (CREATE PROC etc. removed), although A, B, C and D do not exist.

SELECT A.B FROM C WHERE D = 'nope'

But this one fails (as expected):

SELECT A.B FROM C WHERE D IS 'nope' 

So I can easily create a stored procedure that references invalid columns or tables and I won't know until I try to deploy it, which can cause trouble if I'm changing a lot of objects and I need an all-or-nothing deployment. It also means I can't validate our schema using a build server without deploying as well, but I'd like to do one before I attempt the other to ensure the database is kept functional.

The closest I've found to this is the Code Analysis (Project -> Properties) but this is more geared towards best practices than catching errors.

Is VS not able to use the existing schema files to check if my code is correct? Isn't this design-time analysis & validation the main selling point of database projects?

I'm working in VS 2010 Premium, if relevant.

Answer 1

Install SQL Server Data Tools and upgrade your database project to the new (generically named) "SQL Server Database Project" template. I've confirmed that these projects will not build if there are invalid references.

You can upgrade your database project to the new template by simply right-clicking the project and clicking the Upgrade option. I've done this with several of my database projects and had no problems with it, nor did I have any problems adjusting to the new template since the UI and structure are mostly the same. However keep in mind that any automated build processes will need to be updated (see here).