Se você tiver um
CHECK restrição no SQL Server que está desabilitada no momento, você pode usar o código abaixo para reativá-la. Quando você habilita um
CHECK (ou uma restrição de chave estrangeira para esse assunto), você tem a opção de especificar se deseja ou não verificar quaisquer dados existentes na tabela. Abaixo estão exemplos de código para habilitar um
CHECK restrição, especificando cada uma dessas diferentes opções. Exemplo 1 – Habilitar uma restrição usando WITH CHECK
Este é o método recomendado para habilitar seu
CHECK restrições (a menos que você tenha um motivo específico para não usá-lo). Aqui está um exemplo de como habilitar uma restrição chamada
chkJobTitle :ALTER TABLE Occupation WITH CHECK CHECK CONSTRAINT chkJobTitle;
Aqui eu declaro explicitamente
WITH CHECK , que informa ao SQL Server para verificar os dados existentes antes de habilitar a restrição. Se algum dado violar a restrição, a restrição não será habilitada e você receberá um erro. Isso é bom, porque reforça a integridade dos dados.
Quando você cria um novo
CHECK restrição, esta é a configuração padrão. No entanto, quando você habilita uma restrição existente (como estamos fazendo aqui), ela não a configuração padrão. Exemplo 2 – Habilitar uma restrição usando WITH NOCHECK
Neste exemplo, a restrição é habilitada sem verificar os dados existentes:
ALTER TABLE Occupation WITH NOCHECK CHECK CONSTRAINT chkJobTitle;
Aqui eu declaro explicitamente
WITH NOCHECK , que informa ao SQL Server para não verificar os dados existentes. Isso significa que a restrição será habilitada mesmo que a tabela já contenha dados que violem a restrição. Esta é a configuração padrão ao habilitar uma restrição (mas não ao criar uma).
Uma das poucas razões (provavelmente a única razão) que você usaria isso é se você deseja manter dados inválidos no banco de dados. Talvez você tenha uma exceção única em que deve inserir uma linha ou mais de dados inválidos, mas exige que todos os dados futuros estejam em conformidade com a restrição.
No entanto, ainda existem riscos associados a fazer isso. Aqui está o que a Microsoft tem a dizer sobre isso:
Não recomendamos fazer isso, exceto em casos raros. A nova restrição é avaliada em todas as atualizações de dados posteriores. Quaisquer violações de restrição suprimidas porWITH NOCHECKquando a restrição é adicionada pode fazer com que atualizações futuras falhem se atualizarem linhas com dados que não seguem a restrição.
Então, usando
WITH NOCHECK poderia causar problemas mais tarde. Exemplo 3 – Habilitar uma restrição usando a opção padrão
Aqui está um exemplo usando a opção padrão:
ALTER TABLE Occupation CHECK CONSTRAINT chkJobTitle;
Este exemplo é o equivalente ao exemplo anterior. Como não especifiquei se deve ou não verificar, o SQL Server assume que eu quero
WITH NOCHECK . Usar WITH NOCHECK remove a confiança
Quando você habilita uma restrição usando
WITH NOCHECK , uma consequência da qual você deve estar ciente é que o SQL Server não confia mais nessa restrição. Ele sinaliza como não confiável. Sim, você leu certo. Na verdade, existe um
is_not_trusted sinalizar que o SQL Server define como 1 quando você desativa um CHECK restrição (o que significa que não é confiável) e a única maneira de defini-la como 0 (confiável) é especificar WITH CHECK ao reativar a restrição. Usando WITH NOCHECK só não corta. Isso faz todo o sentido. Afinal, você confiar em uma restrição que não verificou todos os dados?
Usando
WITH CHECK , você garante que a restrição verifique todos os dados existentes antes de ser habilitada. A única maneira de habilitar é se todos os dados existentes estiverem em conformidade com a restrição. Depois de verificar todos os dados existentes, ele pode ser confiável. Para saber mais sobre isso, consulte O que você deve saber sobre WITH NOCHECK ao habilitar uma restrição CHECK no SQL Server, onde você pode ver o
is_not_trusted real sinalizador sendo alternado para frente e para trás toda vez que desabilito e reabilito um CHECK limitação. 
