一括挿入後に外部キーが信頼できなくなる

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それぞれで使用）が、その後すぐに信頼できなくなります。実行される保守ジョブのみが午前AMのOlaであり、これは1日中行われます。

更新：

したがって、可能性を絞り込むためにいくつかのトレースを行った後、それBULK INSERTが原因でFKが信頼されなくなる可能性があります。このmsdnの質問は、これがキーが信頼されなくなるための有効なルートであることを示しています。これは私が聞いた最初のルートです。

だから私の質問は、BULK INSERT外部キーのis_trustedステータスを維持できる使用する代替戦略はありますか？1時間に数回実行されるアプリケーションのコンテキストで実行されています。代わりに、開発者に挿入ステートメントをバッチ処理させることもできますが、BULK INSERT必要がない場合は、最終通告を使用しないようにします。

BULK INSERT私たちのアプリケーションからのA は、MSDNの質問で確認されたように、信頼できない外部キーの原因でした。と同様にBCP、a BULK INSERTが実行されるときはいつでも、挿入中に外部キーはチェックされないため、信頼されません。

Kinが述べたように、信頼できない外部キーを見つけて修正するために利用できる簡単なスクリプトがありますが、私のシナリオでは、挿入は頻繁に発生しており、この問題を常に修正しようと努力していますが、価値はありません。

ypercubeは、一括挿入内のCHECK_CONSTRAINTS オプションを使用することを提案しました。これにより、制約に従うことが強制されます。

私は開発者と共にレビューして、の各使用がBULK INSERT挿入された行に関して正当化されることを確認します。そうでない場合は、それに対応する必要があります。