Les clés étrangères ne sont plus fiables après l'insertion en bloc

Dans un serveur de l'édition SQL 2014 (12.0.2430.0 - pas encore de SP1) avec une base de données en mode de compatibilité 2012 (travail pour le faire passer à 2014 ...) J'ai une poignée d'objets de clé étrangère qui sont systématiquement marqués comme not trusteddans la base de données . Je les ai supprimés et recréés sans NOCHECKoptions, mais en 5 à 10 minutes, ils ne sont plus fiables et si je génère un CREATEscript, il se présente comme suit:

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

Le script de création utilisé est:

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

Il n'y a pas de réplication, il n'y a pas d'outils tiers et je surveille toutes les instructions DDL sur la base de données, donc ce n'est pas un autre utilisateur.

Je suis en mesure de vérifier très bien les contraintes (en utilisant WITH CHECK CHECKsur chacune) mais elles ne sont toujours pas fiables peu de temps après. Seuls les travaux de maintenance exécutés sont ceux d'Ola au début de la matinée et cela se produit tout au long de la journée.

Mise à jour:

Donc, après quelques traces pour restreindre les possibilités, il semble que cela BULK INSERTpuisse faire en sorte que le FKdevienne non fiable. Cette question msdn indique qu'il s'agit d'un itinéraire valide pour que la clé ne soit pas approuvée, ce qui est la première fois que j'en entends parler.

Ma question est donc la suivante: existe-t-il une stratégie alternative à l'utilisation BULK INSERTqui peut conserver le is_trustedstatut de clé étrangère ? Il est exécuté dans le contexte d'une application exécutée plusieurs fois par heure. Je pourrais demander aux développeurs de grouper leurs instructions d'insertion à la place, mais je préférerais ne pas mettre un ultimatum sur l'utilisation BULK INSERTsi je ne le dois pas.

Un BULK INSERTde notre application a été la cause de clés étrangères non fiables, comme l'a confirmé une question MSDN . De manière similaire à BCP, chaque fois que a BULK INSERTest effectué, la clé étrangère n'est pas vérifiée lors de l'insertion, ce qui la rend non fiable.

Comme Kin l'a mentionné, il existe des scripts simples pour trouver et corriger les clés étrangères non fiables, mais dans mon scénario, les insertions se produisent à une fréquence qui fait l'effort de résoudre constamment ce problème qui n'en vaut pas la peine.

Et ypercube a suggéré d'utiliser l' CHECK_CONSTRAINTS option dans les inserts en vrac qui obligerait à respecter la contrainte.

Je prévois de passer en revue avec les développeurs pour m'assurer que chaque utilisation de BULK INSERTest justifiée en termes de lignes insérées, sinon cela devra être quelque chose à vivre.