Tuesday, March 27, 2012 4:26 PM
It looks like SSDT supports only suppressing warnings but not errors. I have many errors, all stating:
Error 4 SQL71561: View: [dbo].[x] has an unresolved reference to object [DB1].[dbo].[y].[column]
I do not want to reference DB1 in this database project, for specific reasons. I just want these errors to be ignore when I build the project. The only way I have been able to get ride of these errors is to go to each file (view) and set the Build Action to None. Suppressing TSql Warnings at the project level or the file level does not work (I'm assuming this only suppresses warnings). And, I have not set the option to treat T-SQL warnings as errors.
Is there a better approach?
- Edited by Hossein Aarabi Tuesday, March 27, 2012 4:30 PM
Tuesday, March 27, 2012 6:01 PM
You need to add second project and import the DB1 that you are referencing into this project, then make Database reference to this new project from your orginal project.
Tuesday, March 27, 2012 6:57 PM
I do want to reference DB1 in this database project, for specific reasons.
I want the compiler to ignore any references to DB1.
Tuesday, March 27, 2012 8:57 PM
First of all references are not treated as errors they are treated as warnings - the only way you could have enabled those as errors is if you have Static Code analysis enabled and have the options checked to treat warnings as errors and you have the option set to Enable analysis on each build.
Double check your static analysis rules and uncheck the option "Enable Code Analysis on Build" to prevent those errors to pop-up on each build. In most cases you want to run Static Code Analysis on demand if you are sure that you have to many of those rules that may break the build.
Tuesday, March 27, 2012 10:08 PM
In this case, the error messages I receive are real errors, not warnings treated as errors.
- I disabled the "Enable Code Analysis on Build" option. This does not resolve my issue.
- In the Project properties > Build tab, "Treat T-SQL warnings as errors" option is disabled.
- In the Project properties > SQLCLR Build tab, in the Treat warnings as errors section, the option is set to None.
- In the Project properties > Project Settings tab, the "Enable extended T-SQL verification for common objects" option is disabled.
- If I enter the error id 71561 in the "Suppress warnings", the compiler ignores it because these are errors and not warnings. I did this at the project level and at the file level. In both cases, the entry is ignored.
This is the Build output:C:\Windows\Microsoft.NET\Framework\v4.0.30319\Csc.exe /noconfig /nowarn:1701,1702 /nostdlib+ /errorreport:prompt /warn:4 /define:DEBUG;TRACE /reference:C:\...\somedll.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll /debug+ /debug:full /optimize- /out:obj\Debug\MyDatabase.dll /target:library /warnaserror- "C:\Users\...\AppData\Local\Temp\.NETFramework,Version=v3.5.SqlClrAttributes.cs"
Loading project references...
Loading project files...
Building the project model and resolving object interdependencies...
Validating the project model...
and then the errors show up.
- Edited by Hossein Aarabi Tuesday, March 27, 2012 10:34 PM
Wednesday, March 28, 2012 2:32 PM
I've read your original post and it makes sense to me now that this is an error since you are referencing external table in the view.
Imagine you need to create a view on the SQL server instance without your DB1 reference that you are putting (without the external table access) - the view will not "compile" and will not be created. In stored procedures however you can ignore the reference and you can compile it - it will fail at runtime when executed but it will compile as the stored procedure does not really care about the external tables untill you want to access it (the query analyser will fail). Well the same is true for the database model in SSDT, external tables must be accessible (referenced) and exist when creating/compiling those views. This is why your build fails at validating the project model, as those views are invalid in the model as they can not compile without their external tables beeing referenced.
You do not have this referenced DB in your solution and I am 100% sure that you will have to create a reference to the DB1. What is the issue with creating the reference anyhow ? Why you do not want it ? It does not have to be the real DB that you are referencing - just new project with table/views that you are trying to reference, heck not even full table definitions only the columsn you need to reference. Having done this will definitly pass your build.
Friday, March 30, 2012 5:22 AM
Thanks, what you say makes sense.
The reason I cannot reference DB1 in the current DB is because of the inter-dependency between the two databases. DB1 references the current DB, and vice versa. These two databases were created by a third-party vendor; we are refrained from modify the code. The other issues (huge size, encrypted views) are really not a problem. Added to that it is not just DB1, there is DB2, DB3,..., DB15. So that makes it 15 DBs that are referenced by the current DB. Awful design.
I think since we are not going to modify their views, stored procedures, etc. If I set the Build Action to none we will be OK. If not for sure I will take your approach, I will trim DB1 thru DB15 to exactly what the current DB needs to reference and import DB1 thru DB15.
- Edited by Hossein Aarabi Friday, March 30, 2012 5:28 AM
Monday, May 21, 2012 4:47 PM
I am having the same issue where I have a view that references tables in another database. (The other database is in its own database project and I want them to be seperate.)
Setting the build action to none kills the errors (they are errors and not warnings, even though"code analysis on build" is not checked) but the update action defaults to deleting the views.
Is there a way to have the SSDT ignore references to other databases?
Thursday, July 19, 2012 6:16 PM
How can I create a database project for a non-SQL Server database that is used via a Linked Server? The database the Linked Server points to is not of a type supported by Visual Studio. My views that access this database work just fine, but VS/SSDT will not let me run a schema compare when I have such views.