SQL71501 - How to get rid of this error?

Question

We use two schemes in our project ( dbo + kal ).

When we try to create a view with the following SQL statement, Visual Studio appears as an error in the error list.

 CREATE VIEW [dbo].[RechenketteFuerAbkommenOderLieferantenView] AS SELECT r.Id as RechenkettenId, r.AbkommenId, r.LieferantId, rTerm.GueltigVon, rTerm.GueltigBis, rs.Bezeichnung, rs.As400Name FROM [kal].[Rechenkette] r JOIN [kal].[RechenketteTerm] rTerm ON rTerm.RechenketteId = r.Id JOIN [kal].[Basisrechenkette] br ON rTerm.BasisrechenketteId = br.Id JOIN [kal].[Rechenkettenschema] rs ON rs.Id = br.Id WHERE r.RechenkettenTyp = 0 

The error message is as follows:

SQL71501: Computed column: [dbo]. [RechenketteFuerAbkommenOderLieferantenView]. [AbkommenId] contains an unresolved object reference. Either the object does not exist, or the link is ambiguous, because it can refer to any of the following objects:
[kal]. [Basisrechenkette]. [r] :: [AbkommenId], [kal]. [Rechenkette]. [AbkommenId], [kal]. [Rechenkette]. [r] :: [AbkommenId], [kal]. [Rechenkettenschema]. [R] :: [AbkommenId] or [kal]. [RechenketteTerm]. [R] :: [AbkommenId].

Publishing the view and working is fine, but it’s rather unpleasant to see the error message all the time when we are building a project where all serious errors are lost when these sql errors are shuffled.

Do you have any ideas what the problem is?

Answer 1

I have found a solution. Although I cannot read yours (what seems German) is enough to know if you are referencing system views, if so, you must provide a database link for the wizard. Otherwise, adding any other necessary database links should solve the problem.

This is described here for system views: Repair the link to the object information schema tables

and for other database links .

See here for more information: Resolution of ambiguous references in an SSDT project for SQL Server

Answer 2

We have a project containing a view that references a function with a table in another database. After adding the database link, which is required to resolve the fields used in the remote database, we still get this error. I found that the table rating function was defined using "SELECT * FROM ...", which was old code created by someone not familiar with good coding methods. I replaced the “*” part with numbered fields and compiled this function, and then re-created dacpac for this database to capture the resulting schema and included the new dacpac as a reference to the database. Woo hoo! controversial links have disappeared! It seems that the SSDT engine cannot (or does not) always have the ability to reach down in the bowels of the aforementioned dacpack to return with all the fields. Of course, the projects that I work on are usually quite large, so I think it makes sense to give all the tools all the help they need, asking them to check your code.