I have a Visual Studio database project which I cannot build because of many SQL71501 errors.
Error SQL71501: Computed Column: xxxxx contains an unresolved reference to an object.
Either the object does not exist or the reference is ambiguous because it could refer to any of the following objects.
The reason for the errors is that I have created a View which references an external table. The external table cannot be added into Visual Studio either as code, or as a reference. These external data sources and external tables are handled by a different process when the database is created. Plus, the external tables and external data source have variable names based on the environment which makes adding them into VS impossible. Technically they could be added as dynamic SQL, but then this breaks the security model, which is a different story :(
If it would simply ignore these errors, build and deploy, everything would be okay. But even though I have told Visual Studio to ignore these, it doesn't appear to have any affect.
How can I suppress these errors and force a build?
Related
I am trying to recreate a SQL Server Database project from a live production database in VS2022. I extracted all the different databases from the server as *.dacpac and imported them into VS2022, established the references between them and so on.
Now I've got the problem, that in the life database there are additional Stored procedures and functions in the master, that were added by the developers and are not part of the default masters database that comes with the SQL Server installation.
Thus the references from the databases to these procedures and functions are unresolved, when I reference the System master database. So I created a .dacpac from the live master database and provided it as master reference instead of the system master database. But if I do that, I get other errors:
I have to manually prefix every use of functions or procedures, that are in the master database as master.dbo.some_function instead of simply some_function.
I get errors and warnings for unresolved references to tables like sysobjects and some standard functions and procedures like SP_EXECUTESQL, that are in the master, even if I prefix them:
SQL71502: Procedure: [dbo].[someProcedure] has an unresolved reference to object master.[dbo].[SP_EXECUTESQL]
Number one is annoying but a problem that I can handle, but number two gives me headaches. How do provide references to a master database, that includes both, the user added functions and procedures and the systems default methods and tables? IS there a way to create a .dacpac including the System databases?
I am having trouble getting Visual Studio 2022 (and 2017) to work with a simple Database Project. I have extracted a data tier application and stored it as a .dacpac file. I have added it as a database reference (Same server, different database.)
It is happy with this and can build and deploy it:
CREATE VIEW [dbo].[View1]
AS SELECT * FROM [$(CBS_ODS)].dbo.rm_acct
But this gives errors:
CREATE VIEW [dbo].[View1]
AS SELECT _IsCurrent FROM [$(CBS_ODS)].dbo.rm_acct
Specifically the two errors:
SQL71561: Computed Column: [dbo].[View1].[_IsCurrent] has an unresolved reference to object [$(CBS_ODS)].[dbo].[rm_acct].[_IsCurrent]
SQL71561: View: [dbo].[View1] has an unresolved reference to object [$(CBS_ODS)].[dbo].[rm_acct].[_IsCurrent]
At this point I've come to the conclusion that Database Projects are unusably buggy. Is there (a) any solution to this or (b) any way to turn of parsing/inspection entirely? It seems like the database references can see views, but not the columns in the views?
I think I've found the solution. Basically you need to add the database you're referring to as a reference, as well as all databases that reference refers to! ie. transitive references aren't automatic.
Pretty annoying as it means that the database reference isn't properly encapsulated from the user's point of view.
SSDT complains that within the code of a stored procedure, a referenced table does not exist. Warning SQL71502.
But the table does exist, and its definition is valid. The table is not in another database, and it even appears correctly in intellisense menus. This is a very straightforward, small database and the problem is just between a local stored procedure and a local table. Both scripts are set to Build.
How can I remove this invalid warning?
Solved - sometimes you just have to step away for a bit. A pair of parentheses in the stored procedure was tripping up SSDT. It did not cause a build error or syntax error, but was confusing the parser somehow such that the name of the table could not be correctly linked to the definition of the table.
I've imported an existing database into a database project in Visual Studio. I'm getting a few types of warnings which I want to make go away:
The database objects have quite a few references to the name of other databases. For example,
SELECT * FROM [databaseA]..Test t1 INNER JOIN [databaseB]..Test t2 on t1.id = t2.id
Is there a simple way to either resolve these warnings or, if necessary, just suppress these warnings? I don't want to have to make separate projects for the other databases, as they are for self-contained 3rd party applications whose schema we don't touch.
We are getting some warnings for using OPENROWSET in a few procedures. I understand that VS cannot safely verify these operations at build time, but I want to suppress these warnings.
For reference, we're using VS 2012 Pro.
You can just create a dacpac file for the other databases using SQLPackage.exe (assuming you're using SQLProj files). If you're using DBProj files, you'll want to use VSDBCMD.exe to create DBSchema files. Put those someplace your projects can reference them and add them as database references. You don't need to create separate projects for them, but do need some way to indicate that those databases are valid.
To suppress warnings, you can take the warning number and either tweak the properties of the file(s) to suppress the warning or you can go to your project properties to suppress warnings for all files. The list can be entered in a CSV format so multiple warnings can be suppressed.
I am using Visual Studio 2008 Database Project GDR2 to manage multiple databases and I am getting a number of errors related to synonyms.
Project-A has a reference to Project-B because Project-A has a number of synonyms to tables in Project-B. The full error I'm getting is "TSD04105: The model already has an element that has the same name dbo.[OBJECT]". This always points at the synonym.
The issue seems to be that the synonym on Project-A has the same name as the table on Project-B. Obviously I could rename all my synonyms so that they have different names than the tables, but this introduces a LOT of work on my part (there's over 140 synonyms so far).
Removing the reference to Project-B will get rid of that error, but instead all of my stored procedures in Project-A generate errors because it can't reference the tables in Project-B any more.
Is there a way to fix this problem short of renaming all the synonyms? What is the appropriate way to handle this situation in the Database Project?
I had this issue between a 2008 server project and a database project and I solved it by using a literal Database Variable Value.
Referencing project properties -> References Tab -> Database Variable Value
I would say that you could also use a Database Variable Name/Value pair as well.
At my previous employer we prefaced each item with item type.
syn_BeerName
vw_BeerName
tblBeerName
Usually, synonym to view, view to table.