We managed to roll out a stored procedure with an error in it because DBPro saw it as a warning rather than an error. A stored procedure was referencing a table which didn't exist, and the warning was:
Warning 97 TSD3012: The following dependencies are missing from your database project: [dbo].[tblFTuser], [dbo].[tblFTuser].[intTFTUfusionid]. Your database application might fail at runtime when [dbo].[spTFTUupdateUser] is executed. C:\SourceControl\Europa\Europa - Development\Callisto\Schema Objects\Stored Procedures\dbo.spTFTUupdateUser.proc.sql 1 1 Callisto
This looks similar to TSD3025, when cross database references can't be resolved (fair enough) but when the schema object belongs in the same database and can't be found shouldn't this be an error?
If you make a stored proc that works fine like:
SELECT [someid], [description] FROM [dbo].[mytable]
And then change the table name to something that doesn't exist, you get the warning above. If you change one of the column names to something that doesn't exist you get an error. Is it safe to change TSD3012 into an error rather than a warning?
This is expected behavior and matches SQL Server in respect to the CREATE PROCEDURE statement. Stored procedures have deferred name resolution which allows a sproc to be created for a table that does not exist yet. During compilation and before execution in SQL Server all the objects referenced in the sproc are resolved. In VSTSDB, we provide a warning that the sproc references objects that cant be resolved and may cause issues at run time. When the referenced object does exist, but the sproc is referencing child objects (columns) that do not match the object's definition then it is an error since this will surely cause a runtime error and will not compile. This is also the same in SQL Server.
There is an option in the project properties (Project Properties -> Build -> Treat warnings as errors) which will flag the deferred name resolution warning for stored procedures as errors. It will also treat all warnings as errors.
