Chaves estrangeiras não são confiáveis ​​após inserção em massa

Em um servidor de edição SQL 2014 (12.0.2430.0 - ainda sem SP1) com um banco de dados no modo de compatibilidade 2012 (trabalhando para alternar para 2014 ...), tenho um punhado de objetos de chave estrangeira que são marcados de forma consistente not trustedno banco de dados . Soltei e os recriei sem NOCHECKopções, mas em 5 a 10 minutos eles não são mais confiáveis ​​e, se eu gerar um CREATEscript, ele sairá como:

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

O script de criação que está sendo usado é:

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

Não há replicação, não há ferramentas de terceiros e estou monitorando todas as instruções DDL no banco de dados para que não seja outro usuário.

Eu sou capaz de verificar bem as restrições (usando WITH CHECK CHECKem cada uma), mas elas ainda não são confiáveis ​​pouco depois. Somente os trabalhos de manutenção executados são da Ola no início da manhã e isso acontece ao longo do dia.

Atualizar:

Então, depois de alguns traços para diminuir as possibilidades, parece que um BULK INSERTpode estar causando a FKfalta de confiança. Esta pergunta do msdn afirma que esta é uma rota válida para a chave não ser confiável, que é a primeira vez que ouvi falar dela.

Portanto, minha pergunta agora é: existe uma estratégia alternativa para o uso BULK INSERTque possa manter o is_trustedstatus de chave estrangeira ? Ele está sendo executado no contexto de um aplicativo em execução várias vezes por hora. Eu poderia fazer com que os desenvolvedores agrupassem suas instruções de inserção em vez disso, mas eu preferiria não usar ultimato BULK INSERTse não fosse necessário.

Um BULK INSERTdos nossos aplicativos foi a causa de chaves estrangeiras não confiáveis, conforme confirmado por uma pergunta do MSDN . De maneira semelhante BCP, sempre que a BULK INSERTé executada, a chave estrangeira não é verificada durante a inserção, portanto não é confiável.

Como Kin mencionou, existem scripts simples disponíveis para encontrar e corrigir chaves estrangeiras não confiáveis, mas no meu cenário as inserções estão acontecendo com frequência, o que faz um esforço para corrigir constantemente esse problema, não vale a pena.

E o ypercube sugeriu o uso da CHECK_CONSTRAINTS opção nas inserções em massa que forçariam a restrição a ser obedecida.

Eu pretendo revisar com os desenvolvedores para garantir que cada uso BULK INSERTseja justificado em termos de linhas inseridas; caso contrário, terá que ser algo para se conviver.