Puede usar el siguiente código para habilitar todos los CHECK y restricciones de clave externa para la base de datos actual en SQL Server.
Cuando habilitas un CHECK o restricción de clave externa, tiene la opción de verificar los datos existentes en la tabla antes de habilitar la restricción. Hacer esto le permite verificar si alguno existente viola o no la restricción. Para realizar esta verificación, use WITH CHECK dentro del código, de lo contrario use WITH NOCHECK .
Código de muestra
Aquí se explica cómo habilitar todos los CHECK y restricciones de clave externa dentro de una base de datos. El primer ejemplo verifica los datos existentes, el segundo no.
Con cheque (recomendado):
EXEC sp_MSforeachtable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
Sin Cheque:
EXEC sp_MSforeachtable "ALTER TABLE ? WITH NOCHECK CHECK CONSTRAINT ALL"
También puede proporcionar explícitamente el nombre del argumento (@command1 ) si lo prefiere (obtendrá el mismo resultado de cualquier manera).
Con Cheque:
EXEC sp_MSforeachtable @command1="ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
Sin Cheque:
EXEC sp_MSforeachtable @command1="ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
Estos ejemplos usan el (no documentado) sp_MSforeachtable procedimiento almacenado. Este procedimiento le permite realizar tareas en cada tabla de una base de datos. Así que es perfecto para nuestra tarea aquí:habilitar todos los CHECK y restricciones de clave externa dentro de la base de datos actual.
A continuación se muestra un ejemplo en el que hago esto y luego compruebo el resultado.
Ejemplo 1:revisar las restricciones
Primero, echaré un vistazo rápido al CHECK actual y restricciones de clave externa en la base de datos, para ver si están habilitadas o deshabilitadas.
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 | +----------------+-----------------+---------------+------------------+
Así que actualmente hay cuatro CHECK restricciones restricciones en la base de datos, para dos tablas diferentes.
Podemos ver que todas las restricciones están deshabilitadas, porque is_disabled está establecido en 1 .
Además, no son de confianza porque is_not_trusted también se establece en 1 .
Ejemplo 2:habilite las restricciones con WITH CHECK
Ahora habilitaré todas las restricciones usando WITH CHECK argumento:
EXEC sp_MSforeachtable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
Siempre es una buena idea asegurarse de que está utilizando la base de datos correcta al hacer este tipo de cosas. Entonces podríamos modificar el código cambiando primero a la base de datos correcta:
USE Test; EXEC sp_MSforeachtable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
En este caso, cambio a una base de datos llamada Test antes de ejecutar el procedimiento almacenado.
Ejemplo 3:comprobar el resultado
Habiendo ejecutado el código anterior, ahora ejecutaré la misma consulta del primer ejemplo para ver el 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 | +----------------+-----------------+---------------+------------------+
Entonces, todas las restricciones en la base de datos ahora se han habilitado (porque is_disabled la columna se establece en 0 para todas las restricciones).
También podemos ver que is_not_trusted la columna también se establece en 0 . Esto significa que se confía en la restricción. Es de confianza, porque logramos que verifique todos los datos existentes antes de habilitarlo.
Si hubiera usado WITH NOCHECK , las restricciones permanecerían sin confianza (es decir, su
is_not_trusted
la bandera se establecería en
1
). Esto se debe a que la base de datos podría contener datos que violan una (o más) de las restricciones (es posible que hayan ingresado datos no válidos a la base de datos mientras las restricciones estaban deshabilitadas).
En raras ocasiones, es posible que deba conservar datos no válidos en la base de datos. En tales casos, la restricción deberá permanecer como no confiable, porque los datos existentes no pasarían la verificación inicial y, por lo tanto, la restricción no podría habilitarse a menos que use WITH NOCHECK .
Consulte Lo que debe saber acerca de WITH NOCHECK al habilitar una restricción CHECK en SQL Server para obtener un ejemplo detallado de cómo cambiar entre confiable y no confiable al deshabilitar y volver a habilitar una restricción.
Habilite las restricciones individualmente
Si solo desea habilitar las restricciones una por una, consulte Cómo habilitar una restricción CHECK en SQL Server y Cómo habilitar una clave externa en SQL Server.
