I've created a SQL Server database project in Visual Studio 2013 and imported a DACPAC taken from a production database. When I tried to build the project I get hundreds of SQL71501 and SQL71561 errors (both of which are "unresolved reference to an object"). Examining the scripts the problem is that many views and stored procedures use three part names: [database].[schema].[object].
It appears that Visual Studio 2013 throws this error whenever it comes across a three part name that includes the database represented by the database project. eg If the database project represents database "MyDatabase" and a SQL script in that project includes something like SELECT t.Column1 FROM MyDatabase.dbo.MyTable t then VS 2013 throws either SQL71501 or SQL71561 when I build the project.
Is there any way of suppressing unresolved reference errors that just apply to the current database? I still want Visual Studio to throw errors for unresolved references to external databases.
EDIT, Correction: Originally stated the error code was SQL71501. However, it appears Visual Studio throws both SQL71501 and SQL71561 errors for unresolved references to the same database.
Well actually there are two workarounds. My personal opinion is that there is a bug in SSDT concerning 3-part object names in the current database.
Create your project snapshot (dacpac) and reference it as a database reference. Remember to clear database variable field in the 'Add database reference' dialog.
It works however this approach is not recommended by Microsoft and can cause other problems:
https://connect.microsoft.com/SQLServer/feedbackdetail/view/1047094/post-deployment-script-is-not-generated-in-the-publish-script
At your code replace all occurrences of MyDatabase.dbo.MyTable with [$(DatabaseName)].dbo.MyTable
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/1863d960-d32d-4920-9a30-13dc86c6f857/sql71562-unresolved-reference-to-object-followd-by-database-name-in-the-same-project?forum=ssdt&prof=required
In Visual Studio:
1) Open SQL Object Explorer, link your database server, right click on unresolved reference database and "Extract Data tier application"
2) Insert a file path. Normally I use \Documents\SQL Server Management Studio\DAC Packages\ and click OK
3) Waiting for extraction
4) Right click on your project References and Add Database Reference
5) Then replace references in your functions, SP, .. with [$(YourDB)] prefix
Related
My database projects in Visual Studio have recently starting throwing these unresolved reference errors every time any create table file in the project is touched.
SQL71501: Column: ___ has an unresolved reference to Built-in Type [int].
SQL71501: Column: ___ has an unresolved reference to Built-in Type [datetime].
SQL71501: Column: ___ has an unresolved reference to Built-in Type [varchar].
If I rebuild the project, everything builds with no errors, and the errors flagged by Visual Studio disappear. However, as soon as I edit any file (even as little as adding a space to the end of a file), that file will immediately become plagued with these unresolved reference errors... until I rebuild again. However, as it's a fairly large project, I don't want to spend about a minute rebuilding after every single minor edit.
This project is worked on by several other people, who do not encounter this issue. How can I resolve this?
Update: If I change tabs, the errors for the first tab disappear until I go back to it. I've also disabled all extensions, but the problem still occurs.
Close down Visual Studio, navigate to the project folder and find the .dbmdl file. Delete it. Reopen the project and rebuild it. This should solve the problem.
In my case the solution was to change the target of my SSDT project to a more recent version of SQL Server (right click on the projet/Properties/Project Settings/Target platform).
See: https://www.codeproject.com/Articles/565459/FixingplusSSDTplusunresolvedplusreferenceplustoplu
I have an SSDT project where I recently changed from SQL 2008 to SQL 2012. I re-exported my references DACPAC files using the SQL 2012 SqlPackage and replaced the SQL 2008 DACPACs with the new 2012 versions. Now I am getting unresolved reference errors for all of the referenced databases.
Strangely enough, IntelliSense auto complete works with the objects in the DACPACs. I can get all tables and columns to auto-complete and show their datatypes, even on the object SSDT is complaining about.
Is there a know issue with SSDT when migrating versions? I have another project using these DACPACs and it builds without error.
I would do three things, the first is double check that each dacpac is at 2012 - when I had a mixed project it was a nightmare, mixing versions causes all sorts of issues with references.
Secondly, open each of the dacpacs as a project in Visual studio and make sure that each of them build correctly, it might be a reference from one of those to something in master etc that is causing subsequent build failures.
Finally do a clean of the solution and build just the dacpac project, look for any messages or warnings in the output window, the answer will be there but just hard to see.
ed
I am trying to add a new report to a project in VS 2012. When I try to add a new report using the report wizard, I get a popup that says it could not load an assembly. The weird thing is that the assembly is not one that is referenced by the project.
Also, another developer opened the same project and was able to use the report wizard.
Does anyone know how the list of data sources in the wizard gets populated? It seems like it should be populated from the project, but I think there is something being populated in the data sources list that is referencing this assembly that does not exist.
Any ideas?
I've got two seemingly similar SQL Server Database Projects in two Visual Studio 2013 solutions which give very different results when I build them. One builds fine, with multiple warnings but no errors. The other fails to build with multiple errors.
The thing I find strange is the warnings in the project that builds and the errors in the project that doesn't seem to be the same, apart from the error numbers. Both have almost identical messages.
eg Error:
SQL71561: View: [dbo].[vw_missed_sla] has an unresolved reference
to object [Database2].[dbo].[order_line].
eg Warning:
SQL71562: Trigger: [dbo].[trg_UserStatusType_CHANGE] has an unresolved reference
to object [Database3].[dbo].[ReferenceTable].
My question is: Why in one project do the unresolved references generate only warning SQL71562 messages but in the other project they generate error SQL71561 messages? What is the difference between a SQL71561 error and a SQL71562 warning?
As far as I can see the database properties of each project are identical. I've been through each of the tabs in the two Project Properties screens side by side. Both are targeting SQL Server 2005 databases.
Recently upgraded to VS 2010 from 2008, the previously built solutions are throwing the following error.
Error 14 Encountered multiple versions of the assembly with GUID 'a5851ea0-2f9a-40b2-a73a-cd7db32f09c5'. Try pre-importing one of these assemblies
I tried re-installing VS 2010 and it didnot help. Any ideas?
Is it the VS 2010 application itself crashing, or does it not like your solution? Can you open VS 2010 by itself? If so, it sounds like it doesn't like some of your references in one or more of your projects. Check the project references. If that doesn't work, start removing projects until you find the offending one.
This may happen, if you copy-paste-renamed a project file to re-use its settings but didn't changed the project GUID of it. Also could be a project migration error, anyway you will have to manually edit the project file and remove the duplicate references if the project fails to load because of the error.
I had the same issue when migrating 2008 -> 2013.
It was caused that we use same linked AssemblyInfo.cs for all projects in solution.
And only for the assembly that used some COM objects (MSMQ) it seems that it starts looking on referenced assemblies GUID and two of them from our solution...
So when I provide individual AssemblyInfo.cs for projects with unique GUIDs it start working.
Hope this info will helpful.
Try to remove the references to the debug folder.
In Visual Studio right click on Project
Select Properties
Select the references tab.
Check to see if any of the references are from the obj\Debug folder and remove them.
See similar question here.