关于 sql:SQL71501 – 如何摆脱这个错误？

SQL71501 - How to get rid of this error?

我们在项目中使用了两个模式 (dbo kal)。

当我们尝试使用以下 SQL 语句创建视图时，Visual Studio 在错误列表中显示为错误。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

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

错误信息如下所示：

SQL71501: Computed Column: [dbo].[RechenketteFuerAbkommenOderLieferantenView].[AbkommenId] 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:
[kal].[Basisrechenkette].[r]::[AbkommenId], [kal].[Rechenkette].[AbkommenId], [kal].[Rechenkette].[r]::[AbkommenId], [kal].[Rechenkettenschema].[r]::[AbkommenId] or [kal].[RechenketteTerm].[r]::[AbkommenId].

发布视图和工作很好，但是在构建我们的项目时总是看到错误消息非常烦人，所有严重的错误都会在这些 sql 错误的洗牌中丢失。

你有什么想法，可能是什么问题？

相关讨论

对我来说，我在用户定义的表类型上看到了 SQL71501。原来我的解决方案中的表类型的sql文件没有设置为build。一旦我将构建操作从无更改为构建，错误就消失了。

我知道这是一个老问题，但它是搜索错误时弹出的第一个问题。

在我的情况下，错误阻止我在 Visual Studio 2017 中执行 SqlSchemaCompare。然而，错误是针对不再属于解决方案一部分的表的表/索引。一个简单的清理/重建没有帮助。

重新加载 Visual Studio 解决方案就成功了。

我们有一个项目，其中包含一个视图，该视图引用另一个数据库中的表值函数。添加解析远程数据库使用的字段所需的数据库引用后，我们仍然收到此错误。我发现表值函数是使用 "SELECT * FROM ..." 定义的，这是由不熟悉良好编码实践的人创建的旧代码。我用所需的枚举字段替换了 "*" 部分并编译了该函数，然后为该数据库重新创建了 dacpac 以捕获结果模式，并将新的 dacpac 合并为数据库引用。呜呼！模棱两可的引用消失了！似乎 SSDT 引擎不能(或不)总是能够深入到引用的 dacpac 的内部以返回所有字段。可以肯定的是，我从事的项目通常都很大，所以我认为在要求工具验证您的代码时给予工具所有帮助是有意义的。

虽然这是一个老话题，但它在搜索引擎上的排名很高，所以我会分享对我有用的解决方案。

我遇到了与 CREATE TYPE 语句相同的错误代码，该语句位于我的 Visual Studio 2017 SQL Server 项目的脚本文件中，因为我找不到如何从界面中专门添加用户定义的类型.

解决办法是，在 Visual Studio 中，除了可以通过右键单击 > 添加看到的那些之外，还有许多可编程文件类型。只需选择新元素并使用搜索字段来查找您要创建的元素。

来自博客文章 Resolving ambiguous references in SSDT project for SQL Server 的最后一段，在答案 https://stackoverflow.com/a/33225020/15405769 中链接：

In my case, when I double clicked the file and opened it I found that
one of the references to ColumnX was not using the two part name and
thus SSDT was unable to determine which table it belonged to and
furthermore whether the column existed in the table. Once I added the
two part name. Bingo! I was down to no errors!