批量插入后，外键变得不受信任

在具有2012兼容模式下数据库的SQL 2014版服务器（12.0.2430.0-尚无SP1）中（正在努力将其切换到2014 ...），我有少数几个外键对象，这些外键对象not trusted在数据库中始终标记为。我删除并重新创建了没有NOCHECK选项的它们，但是在5到10分钟内，它们再次变得不受信任，如果我生成CREATE脚本，它将显示为：

ALTER TABLE [dbo].[Points]  WITH NOCHECK 
ADD  CONSTRAINT [FK_BadgeId] FOREIGN KEY([BadgeId])
REFERENCES [dbo].[Badge] ([Id])
GO

使用的创建脚本为：

ALTER TABLE [dbo].[Points]
ADD  CONSTRAINT [FK_BadgeId] FOREIGN KEY([BadgeId])
REFERENCES [dbo].[Badge] ([Id])
GO

ALTER TABLE [dbo].[Points] CHECK CONSTRAINT [FK_BadgeId]
GO

没有复制，没有第三方工具，而且我正在监视数据库中的所有DDL语句，因此它不是另一个用户。

我能够很好地检查约束（WITH CHECK CHECK在每个约束上使用），但是不久之后它们仍然变得不受信任。只有运行的维护工作是Ola在AM的早期工作，并且整天都在进行。

更新：

因此，在经过几次跟踪以缩小可能性后，似乎BULK INSERT可能导致FK变得不可信。这个msdn问题指出，这是密钥变得不受信任的有效途径，这是我第一次听说。

所以我现在的问题是，有没有一种替代方法BULK INSERT可以保持外键is_trusted状态？它是在每小时运行几次的应用程序的上下文中执行的。我可以让开发人员批处理其插入语句，但是BULK INSERT如果不需要的话，我不希望在使用时使用最后通atum 。

BULK INSERT正如MSDN问题所证实的，我们应用程序中的A 是导致不可信外键的原因。与相似BCP，无论何时BULK INSERT执行a ，插入时都不会检查外键，因此使其不受信任。

正如Kin所提到的，有一些简单的脚本可用于查找和修复不受信任的外键，但是在我的情况下，插入操作的频率很高，这使得不断努力解决此问题不值得。

ypercube建议在批量插入中使用CHECK_CONSTRAINTS 选项，这将强制遵守约束。

我计划与开发人员一起审查，以确保每种用法BULK INSERT在插入的行方面都是合理的，否则就必须适应。