Las claves foráneas dejan de ser confiables después de la inserción masiva

En un servidor de edición SQL 2014 (12.0.2430.0 - aún no SP1) con una base de datos en modo de compatibilidad 2012 (trabajando para cambiarlo a 2014 ...) Tengo un puñado de objetos de clave externa que están marcados constantemente como not trusteden la base de datos . Los descarté y los volví a crear sin NOCHECKopciones, pero en 5 a 10 minutos vuelven a desconfiar y, si genero un CREATEscript, aparece como:

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

El script de creación que se utiliza es:

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

No hay replicación, no hay herramientas de terceros, y estoy monitoreando todas las declaraciones DDL en la base de datos para que no sea otro usuario.

Puedo verificar bien las restricciones (usando WITH CHECK CHECKen cada una) pero aún no se confían poco después. Solo los trabajos de mantenimiento que se ejecutan son de Ola a principios de la mañana y esto sucede durante todo el día.

Actualizar:

Entonces, después de un par de rastros para reducir las posibilidades, parece que BULK INSERTpuede estar causando FKque no se confíe. Esta pregunta msdn indica que esta es una ruta válida para que la clave no sea confiable, que es lo primero que escucho de ella.

Entonces mi pregunta ahora es, ¿existe una estrategia alternativa para usar BULK INSERTque pueda mantener el is_trustedestado de clave externa ? Se ejecuta en el contexto de una aplicación que se ejecuta varias veces por hora. Podría hacer que los desarrolladores procesen sus declaraciones de inserción en su lugar, pero preferiría no poner un ultimátum en el uso BULK INSERTsi no es necesario.

A BULK INSERTde nuestra aplicación fue la causa de claves externas no confiables, según lo confirmado por una pregunta de MSDN . De manera similar a BCP, cada BULK INSERTvez que se realiza un a, la clave externa no se verifica durante la inserción, por lo que no es confiable.

Como Kin mencionó, hay scripts simples disponibles para encontrar y reparar claves foráneas que no son de confianza, pero en mi caso las inserciones ocurren con frecuencia, lo que hace que el esfuerzo por solucionar este problema constantemente no valga la pena.

Y ypercube sugirió usar la CHECK_CONSTRAINTS opción dentro de las inserciones masivas que obligarían a obedecer la restricción.

Planeo revisar con los desarrolladores para asegurarme de que cada uso de BULK INSERTesté justificado en términos de filas insertadas, de lo contrario tendrá que ser algo con lo que vivir.