进行大容量插入时，SSDT Schema Compare不起作用

我正在一个大型ETL和DW项目中工作，在该项目中我们将TFS /源代码控制与SSIS和SSDT一起使用。

今天，我发现，当SSIS包对数据库表执行批量插入时，无法对该数据库执行SSDT架构比较。这很不幸，因为我们的某些软件包需要很长时间才能完成。我们希望使用“模式比较”功能来检测对数据库结构的更改，以便将其保存在我们的SSDT项目中，以进行数据库的版本控制。

仔细研究一下，我发现SSDT中的Schema Compare函数执行一个SQL脚本，该脚本OBJECTPROPERTY()在数据库的表上调用系统函数。特别是在我的情况下，OBJECTPROPERTY(<object_id>, N'IsEncrypted')当<object_id>引用当前正在批量插入的表时，对的任何调用似乎都被阻止了。

在Visual Studio中，SSDT架构比较会在一段时间后简单地超时，并声称未检测到差异。

SSDT中是否有解决此问题的方法，还是应该尝试提交MS Connect错误报告？

或者，由于BULK INSERT来自SSIS包，是否有某种方法可以在不锁定OBJECTPROPERTY表调用的情况下进行此插入？编辑：在SSIS OLE DB目标中，我们可以删除“锁定表”中的复选标记，该标记如其所愿，但这在某些情况下可能会损害性能。我对允许SSDT架构比较执行其工作的解决方案更感兴趣，即使某些对象被锁定。

该OBJECTPROPERTY调用需要架构稳定（Sch-S）锁，该锁仅与架构修改（Sch-M）锁不兼容。

BULK INSERT在某些情况下，此功能将使用Sch-M锁定。这些在“ 优化联机丛书中的批量导入指南 ”的“表锁定和日志记录”部分中列出：

如果目标表是群集的，则可能会发现启用跟踪标志610会有所帮助。请阅读所有这些文章和《数据加载性能指南》，并彻底测试是否决定采用这种方法。

我不知道为什么SSDT检查IsEncrypted表的属性。我无法想象一个有意义的方案，但这是SSDT人员的问题。