由于非聚集索引的依赖性，SSDT 中的更改表删除列失败答案

【问题标题】：alter table drop column fail in SSDT because of dependancy of non cluster index由于非聚集索引的依赖性，SSDT 中的更改表删除列失败
【发布时间】：2014-06-21 06:45:19
【问题描述】：

我为 SQL Server 2012 数据库创建了一个 SSDT 项目。因为我的数据库已经存在于 SQL Server 数据库引擎中，所以我使用导入功能将所有对象导入 SSDT。一切正常，但我现在面临 2 个问题

1) 因为其中一个表使用 HIERARCHYID 列 (col1) 作为数据类型，并且有一个基于 HIERARCHYID 列的计算列。计算列的定义类似于 case Col1= hierarchy.GETRoot() THE NULL ELSE someexpression END。在 SSDT 中导入表脚本后，开始出现未解析引用的错误。如果我将定义更改为 case hierarchy.GETRoot() = Col1 THE NULL ELSE someexpression END（注意现在 col1 现在位于末尾），它可以正常工作。

2) 如果我保留上述解决方案（即在 = 之后保留 col1），那么在发布项目时，SSDT 必须在生产服务器上删除该列，然后重新创建它。由于有一个索引依赖于该列，因此部署失败每次都说像 ALTER TABLE DROP COLUMN 这样的错误失败，因为其他对象访问它。我无法控制 SSDT 如何设计/发布脚本。如果我在发布数据库项目之前必须注意删除每个依赖对象，那么我认为没有用它

请建议我如何解决这个问题

谢谢阿图尔

【问题讨论】：

我遇到了这个确切的问题。我有一个计算列，它上面有一个索引。当 dacpac 部署尝试删除并重新创建索引时，该索引被忽略，部署随后失败。我预计现在必须删除并重新创建索引前后部署脚本，但是一个有效的解决方案将优于解决方法。在这个问题上运气好吗？
确认是我们使用的SSDT版本的问题；请参阅下面的答案。
我的回答最终变成了不回答。我对其进行了编辑，并在用户语音上发布了该错误，因为它仍然存在于 SSDT 的当前版本中。正如我在回答中提到的，目前的解决方法是针对每个场景的部署前和部署后脚本。

标签： sql sql-server deployment sql-server-data-tools

【解决方案1】：

我能够重现您描述的参考分辨率问题。我建议在此处通过 Connect 将该问题提交给 Microsoft：https://connect.microsoft.com/SQLServer/feedback/CreateFeedback.aspx

我无法重现发布失败。 Visual Studio 帮助 > 关于对话框显示安装了哪个版本的 SSDT？最新版本以 40403.0 结尾。如果您没有使用最新版本，我建议您安装它以查看是否可以修复发布失败。您可以使用工具 > 扩展和更新来下载 SSDT 更新。

如果您确实有最新版本，您能否提供一个示例架构来演示该问题？

【讨论】：

谢谢。仅当我们使用任何 CLR 数据类型时，此问题才会存在。我确实尝试对 int 数据类型列做同样的事情，它工作正常。我使用的 SSDT 版本是 11.1.40403.0
您能提供一个示例架构吗？例如。为了重现参考分辨率，我有初始状态脚本： CREATE TABLE [dbo].[Table_1] ( [HID] [sys].[hierarchyid] NOT NULL, [IsRoot] AS ([HID]=[hierarchyid] 时的情况： :GetRoot() then 1 else 0 end));并修改了状态脚本： CREATE TABLE [dbo].[Table_1] ( [HID] [sys].[hierarchyid] NOT NULL, [IsRoot] AS (case when [hierarchyid]::GetRoot()=[HID] then 1 else 0 结束));

【解决方案2】：

将您的项目与生产 dacpac 进行比较，并让它生成脚本以进行更改。然后，如果需要，您可以在将脚本应用于生产之前对其进行编辑。我的开发团队就是这样做的。

【讨论】：

【解决方案3】：

我已经遇到同样的问题好几天了。在找到您的帖子以确认问题出在 SSDT 后，我意识到它可能会在比我们当前使用的版本更高的版本中修复：12.0.50730.0（VS 2013，该项目使用的版本）。

我还从 VS 2017 安装了 14.0.3917.1 版本。我只是尝试过，没有问题。 所以解决方案是升级您的 SSDT 版本。

请忽略该解决方案，我昨晚的成功似乎异常。在恢复存在问题的数据库后，今天尝试重复此操作，但部署未能再次考虑至少一个索引。

编辑：我已经在 User Voice 上发布了这个消息：https://feedback.azure.com/forums/908035-sql-server/suggestions/33850309-computed-column-indexes-are-ignored-with-dacpac-de

此外，为了确保这至少是某种可行的答案，我正在实施的解决方法包括使用部署前和部署后脚本自己删除和重新创建丢失的索引。

如果 dacpac 旨在更新可能与模型有不同程度偏差的各种版本的数据库，这不是一个理想的解决方案，但它对我们有用，因为我们对所有实例都有严格的控制，并且可以预期大致相同delta 为每个数据库实例生成每个版本。

【讨论】：