I am getting an error when using SSDT 2010 (latest updates, v10.3.21208.0) with multiple database projects in a single solution. The error reads the following:
SQL71561: View: [dbo].[View] has an unresolved reference to object [OtherDatabase].[dbo].[OtherTable]
I've read all the other resources I could find on Stack Overflow and Google. Here are some things I've already tried:
Setup Database References to the other projects within the solution.
Cleared out the Database variable option to bypass the SQLCLR variable that dynamically changes your database name based on configuration options.
Ensured that Enable extended Transact-SQL verification for common objects is disabled on all projects
Have the Database location option set to: Different database, same server
Ensured the Project Build Order is arranged logically
Tried the suggestions from this post
Nothing seems to be working for me. Any help would be much appreciated. Here is a screenshot that might shed more light on my problem:
It has been a while, but I still want to share this solution with others that may be following the same lost links I was initially. Pay close attention to step 4. That cleared the issue for me.
A possible solution is to add a database reference to the database that has the missing object. The reference needs a Data-tier Application (dacpac file) that can be easily generated on the solution with the database project that has the missing object. Press the right mouse button over the database project and selected Snapshot Project. The dacpac file is created on the Snapshots folder. The file should then be copied to a common folder for re-usability.
In the project with the error press the right mouse button over the References and selected Add Database Reference. The Add Database Reference dialog appears:
Select the dacpac file
Select the database location. The most common option is "Different database, same server"
Confirm that the Database name field is as expected
Clear the "Database variable" field in the dialog. If this field has a value the queries must use this variable and not the database name
If the referenced database project builds, but the reference isn't resolving, try cleaning and rebuilding the referenced project and cleaning the project doing the referencing.
I'm using VS2015, but it might still apply. In my case, the referenced database had a "Database Variable Name" specified in the reference properties like $(SomeDb). If someone tried to refer to an item in the referenced database using the actual database name instead of the variable, we'd get a warning about an unresolved reference. Changing those to be like [$(SomeDb)].[dbo].[SomeTable] resolved the references.
Related
I have several database references in a database project and I have had to add additional databases because I was getting the same error (but with the name of each database projects), but there is nothing at all inside my solution called master.decpac.
The error is:
The reference to external elements from the source named 'master.dacpac' could not be resolved, because no such source is loaded.
What is master.dacpac and what could I do to resolve the error I'm having?
Thanks
EDIT I have narrowed it down to just one database project. Deleting the database reference to the project will remove the error. While it isn't a viable solution, at least we know it is only one project.
Solved.
master is a system database.
To add it as a reference to your database project you select References > Add Database Reference and then select the System database radio button. In the drop down available, select Master and then select ok.
The system database was referenced in the project and was also needed inside of the new database project.
I have a BizTalk 2013 application comprising of 3 projects - orchestration, schemas and maps.
In my orchestations project I have references to my maps and schemas projects within the same application.
However, when I try to select a map or schema using the referenced assemblies nothing is showing, not even the standard dll's such as System.XML or System.Configuration, the only thing I can see is Microsoft.XLANGs.BaseTypes.
I can see the references in the solution explorer but not when I try to use them in anywhere in the orchestration.
I had this problem before but can't remember how I resolved it, any suggestions?
I ran into the same issue today. The only reference I was seeing was the XLANG.BaseTypes.
Turned out I set build action to none one time when I needed to test something and didn't need this orchestration. Setting it back to BtsCompile fixed it.
After deleting and re-creating the entire project which I seemed not to be able to reference everything is building and referencing as normal. Not sure what caused it in the 1st place though, so still open to suggestions for that.
thanks
In a database project DB2 has references to DB1. When I make a dacpac of DB1 and add a reference to the dacpac in DB2, then the project compiles without error.
Since DB1 and DB2 are in the same solution anyhow, I am trying to add a database reference instead of the reference to the dacpac. Since DB1 and DB2 may reside on different servers with different names in production, I added $(parameters) for databases and servers. The project does not compile:
Error 1069 SQL71561: View: xyz has an unresolved reference to object
[$(server)].[$(dbname)].[someschema].[sometable].
The parameters are set correctly. Did I overlook something concerning database references?
First just to verify that the projects themselves are setup correctly.
You have a project in the solution for DB1.
You have a project in the solution for DB2.
To start with a clean slate (often easiest with database references - you cannot edit properties easily after the reference has been added). Remove any existing database references to DB1 from DB2 project.
Do a clean of the solution.
Build DB1 (Verify that a DACPAC has been created for DB1 in \bin\debug etc) and fix any errors if necessary.
In DB2 add a database reference to a solution item. Right click on References, select Add Database Reference. In the dropdown choose the first item (Database project in the current solution). Choose DB1.
At the bottom, select 'Different Database, Different Server' from the dropdown.
Enter the variables again. Verify that the example usage at the bottom indicates 'SELECT * FROM [$(server)].[$(dbname)].[Schema1].[Table1]' (Or similar depending on your choice of variable names). Take note of that sample and copy that to a note or clip somewhere.
That should resolve the issues. You have already changed the views \ procs to reference the variables.
I think the easiest rule here is if you aren't sure, delete the reference and add it again. There is no easy way to edit variable names etc. In addition, if DB1 build fails, then you will still get reference errors like above.
I hadn't noticed that the referenced database projects in my solution did not compile in Visual Studio because of compile errors. Once the referenced projects compiled, the reference to those projects also worked.
Being able to extract a dacpac in Visual Studio is no indication for the circumstance that the project compiles; when extracting a dacpac directly from a database the external references of that database will be valid while the database project must be provided with those references first.
I am having a very weird problem with building a SQL Server 2008 Database Project from within Visual Studio 2010. I created the database project and then imported the database objects and settings from a local database that I am working with. I then went to build the database project and got the following error:
SQL03006: View: [dbo].[GovCAStaff] has an unresolved reference to object [CTS_Staff].[dbo].[Client_Assignments].
The problem appears to be that the view GovCAStaff is referencing a table in a different database (CTS_Staff). However, I have numerous functions and stored procedures in the same database project that are referencing tables in a different database but the build process only generates warnings for those, not errors. Other than rewriting the view as a function, does anyone know of a way to get rid of this build error? Is this a known limitation of views within database projects? Anyway, I am really stumped. Have googled this topic and haven't found anything relevant. Any help would be greatly appreciated. Thanks in advance.
The reason this error shows up in views, but not functions and stored procedures, is because that is how SQL Server itself will react if the database/table does not actually exist. In other words, in SQL Server you can define stored procedures and functions that reference tables that don't exist or are otherwise inaccessible. Not so for views.
The way to resolve this issue is to add a 'database reference' (a .dbschema file) to your project so that the project build process knows about the schema of that other database. Where to get this magical .dbschema file?
Create another database project (presumably in the same solution) for the other database. This is most convenient, as you can just create a 'project reference' and everything stays up-to-date (you wanted a DB project for that other database, anyway, right?).
Create the .dbschema file manually via vsdbcmd.
If the database is a 'system' database (e.g. 'master' or 'msdb'), you can use one of the pre-built .dbschema files ({Program Files}\Microsoft Visual Studio 9.0\VSTSDB\Extensions\SqlServer{version}\DBSchemas).
I have a database I am using the Visual Studio 2010 Database Project tool vsdbcmd.exe to create a schema from.
vsdbcmd /a:Import /dsp:Sql /model:"Database" /cs:"Server=SqlServer; Initial Catalog=DatabaseName; Integrated Security=SSPI;"
The tool is reporting an error:
Error TSD02016, Gen-259 (12,50) The column name is not valid. No table name was specified.
How would I go about pinpointing where this error is originating?
I have found one resource on the internet (http://social.msdn.microsoft.com....) that points to a possibility of a keyword used incorrectly, but the error messages are not the same.
What is Gen-259?
Thank you,
Keith
I ran into a similar problem and was able to resolve it by using the import function in Visual Studio 2010. I created a new project and used Project -> Import Database Objects and Settings. In the our case, there were stored procedures that had become orphans and referenced columns in a table that no longer existed. We did have to correct some of the errors on the live system before we could get the project to fully import, but we were able to do that and create a .dbschema file which could be used as a reference in other VS projects.