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.
Related
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 have a solution with 2 SSDT database projects, one referencing the other. In one of the stored procedures I have a simple update statement that looks something like the following:
update [$(otherDb)]..OtherTable set TheField = #value where OtherTable.Id = #id
I have many stored procedures that do this very same operation on other tables, this stored procedure has been working for many months, and intellisense even is even able to display all of the columns of the the table. Even still I get an error saying
SQ71561: Procedure [dbo].[MyProcedure] has an unresolved reference to object [$(otherDb)].[dbo].[OtherTable].[TheField]
Any body have any ideas what's going on?
Deleting the DBML files and rebuilding the projects did it
Ensure the underline view does not use SELECT *
Remove the Reference and Add the database reference again,select the check button Suppress Warning....
Rebuild the project- that should solve it
This is Jony Lalwani.
I have installed Visual Studio 2017 and it has the SSDT version 15.1. I checked the usage of variable [$(DATABASE)] in scripts and below are the observations-
1- Stored Procedure, Table Valued Functions & Scalar Functions will only throw unresolved reference warning if you use DB.dbo.Table instead of [$(DB)].dbo.Table. Therefore even if we don’t use the variable the build is successful in these scripts.
2- By design Inline Functions & Views will throw unresolved reference error if we use DB.dbo.Table instead of [$(DB)].dbo.Table. Therefore in these scripts variable references are required.
The above two points are also valid for Visual studio 2013 SSDT (12.0) and it is working same way there as well. However VS 2013 SSDT sometime throws multiple error of unresolved reference also in Stored procedure when we import or update schema from SQL database. This is due to bugs in 2013 SSDT.
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.
I have a SQL CLR project created in VS2010. It needs to run PreDeployScript.sql and PostDeployScript.sql. Both files exist in project. However, when trying to run the deploy, I get the following error messages:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\TeamData\Microsoft.Data.Schema.SqlClr.targets(96,5): Deploy error SQL04105: The model already has an element that has the same name dbo.PropertySetCollection.
This message is repeated for every single type we have. This leads me to believe that PreDeployScript.sql was not run.
Has anybody else run into this issue? Is there a workaround?
Make sure you have not changed the Solution name. If you have you will now be out of sync with the assembly name on the SQL Server. To fix this just drop all the stored procedures for the existing assembly, drop the assembly, then try the deploy again. A new assembly will be created on SQL Server with the Solution name that is in VS.
Try using the Sql Proviler to check if the PreDeploy.sql has run.
Also read this:
https://connect.microsoft.com/VisualStudio/feedback/details/539211/db-projects-with-same-object-names-cannot-be-used-as-database-reference-error-sql04105?wa=wsignin1.0
It is a bug in VS2010 SQL CLR deployment. It has do to with dropping / adding computed columns in pre/post deploy scripts. MS is working on a solution.
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).