Você pode usar o código abaixo para habilitar todos os
CHECK e restrições de chave estrangeira para o banco de dados atual no SQL Server. Quando você habilita um
CHECK ou restrição de chave estrangeira, você tem a opção de verificar os dados existentes na tabela antes que a restrição seja habilitada. Isso permite verificar se algum existente viola ou não a restrição. Para realizar esta verificação, use WITH CHECK dentro do código, caso contrário use WITH NOCHECK . Código de amostra
Veja como habilitar todos os
CHECK e restrições de chave estrangeira em um banco de dados. O primeiro exemplo verifica os dados existentes, o segundo não. Com cheque (recomendado):
EXEC sp_MSforeachtable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
Sem cheque:
EXEC sp_MSforeachtable "ALTER TABLE ? WITH NOCHECK CHECK CONSTRAINT ALL"
Você também pode fornecer explicitamente o nome do argumento (
@command1 ) se preferir (você obterá o mesmo resultado de qualquer maneira). Com cheque:
EXEC sp_MSforeachtable @command1="ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
Sem cheque:
EXEC sp_MSforeachtable @command1="ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
Esses exemplos usam o (não documentado)
sp_MSforeachtable procedimento armazenado. Este procedimento permite que você execute tarefas em cada tabela em um banco de dados. Portanto, é perfeito para nossa tarefa aqui - habilitar todos os CHECK e restrições de chave estrangeira no banco de dados atual. Abaixo está um exemplo onde eu faço isso e depois verifico o resultado.
Exemplo 1 – Revise as restrições
Primeiro, darei uma olhada rápida no
CHECK atual e restrições de chave estrangeira no banco de dados, para ver se estão ou não habilitadas ou desabilitadas. SELECT OBJECT_NAME(parent_object_id) AS 'Table', name AS 'Constraint', is_disabled, is_not_trusted FROM sys.foreign_keys UNION SELECT OBJECT_NAME(parent_object_id), name, is_disabled, is_not_trusted FROM sys.check_constraints;
Resultado:
+----------------+-----------------+---------------+------------------+ | Table | Constraint | is_disabled | is_not_trusted | |----------------+-----------------+---------------+------------------| | ConstraintTest | chkPrice | 1 | 1 | | ConstraintTest | chkValidEndDate | 1 | 1 | | ConstraintTest | chkTeamSize | 1 | 1 | | Occupation | chkJobTitle | 1 | 1 | +----------------+-----------------+---------------+------------------+
Portanto, existem atualmente quatro
CHECK restrições restrições no banco de dados, para duas tabelas diferentes. Podemos ver que todas as restrições estão desabilitadas, porque is_disabled está definido como 1 .
Além disso, eles não são confiáveis, porque is_not_trusted também está definido como 1 .
Exemplo 2 – Habilite as Restrições usando WITH CHECK
Agora vou habilitar todas as restrições usando o
WITH CHECK argumento:EXEC sp_MSforeachtable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
É sempre uma boa ideia garantir que você esteja usando o banco de dados correto ao fazer esse tipo de coisa. Assim, poderíamos modificar o código primeiro alternando para o banco de dados correto:
USE Test; EXEC sp_MSforeachtable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
Neste caso, mudo para um banco de dados chamado Test antes de executar o procedimento armazenado.
Exemplo 3 – Verifique o resultado
Tendo executado o código acima, agora executarei a mesma consulta do primeiro exemplo para ver o resultado.
SELECT OBJECT_NAME(parent_object_id) AS 'Table', name AS 'Constraint', is_disabled, is_not_trusted FROM sys.foreign_keys UNION SELECT OBJECT_NAME(parent_object_id), name, is_disabled, is_not_trusted FROM sys.check_constraints;
Resultado:
+----------------+-----------------+---------------+------------------+ | Table | Constraint | is_disabled | is_not_trusted | |----------------+-----------------+---------------+------------------| | ConstraintTest | chkPrice | 0 | 0 | | ConstraintTest | chkValidEndDate | 0 | 0 | | ConstraintTest | chkTeamSize | 0 | 0 | | Occupation | chkJobTitle | 0 | 0 | +----------------+-----------------+---------------+------------------+
Portanto, todas as restrições no banco de dados foram habilitadas (porque o is_disabled a coluna está definida como 0 para todas as restrições).
Também podemos ver que o is_not_trusted coluna também está definida como 0 . Isso significa que a restrição é confiável. É confiável, porque conseguimos verificar todos os dados existentes antes de ser ativado.
Se eu tivesse usado
WITH NOCHECK , as restrições permaneceriam não confiáveis (ou seja, suas
is_not_trusted
sinalizador seria definido como
1
). Isso ocorre porque o banco de dados pode conter dados que violam uma (ou mais) das restrições (dados inválidos podem ter entrado no banco de dados enquanto as restrições foram desabilitadas). Em raras ocasiões, pode ser necessário manter dados inválidos no banco de dados. Nesses casos, a restrição precisará permanecer não confiável, porque os dados existentes não passariam na verificação inicial e, portanto, a restrição não poderá ser habilitada a menos que use
WITH NOCHECK . Consulte O que você deve saber sobre WITH NOCHECK ao habilitar uma restrição CHECK no SQL Server para obter um exemplo detalhado de alternar entre confiável e não confiável ao desabilitar e reabilitar uma restrição.
Ative as restrições individualmente
Se você deseja habilitar apenas as restrições uma a uma, consulte Como habilitar uma restrição CHECK no SQL Server e Como habilitar uma chave estrangeira no SQL Server.
