ALTERAR TABLA VERIFICAR RESTRICCIÓN

25

Desde el Explorador de objetos en SQL Server, al seleccionar y escribir una restricción de clave foránea, se genera el siguiente código.

     USE [MyTestDatabase]
     GO

     ALTER TABLE [dbo].[T2] WITH NOCHECK ADD CONSTRAINT [FK_T2_T1] FOREIGN KEY([T1ID])
     REFERENCES [dbo].[T1] ([T1ID])
     GO

     ALTER TABLE [dbo].[T2] CHECK CONSTRAINT [FK_T2_T1]
     GO

¿Cuál es el propósito de la última declaración "ALTER TABLE CHECK CONSTRAINT"? No parece importar si se ejecuta o no. No falla en los datos incorrectos existentes, ni cambia que la restricción se aplicará a los datos nuevos.

¡Gracias!

sql-server-2008

— Delux
fuente

23

Asegura que la restricción esté habilitada después de su creación. Su ALTER TABLEdeclaración incluye WITH NOCHECKcuál es la pieza que dice no verificar los datos incorrectos existentes durante la creación de la restricción.

Tal como está escrito, los datos existentes no serán verificados contra la restricción debido WITH NOCHECKa la primera declaración. La emisión de la segunda declaración permitirá la verificación contra la restricción para cualquier cambio futuro en la tabla que esté cubierto por la restricción, hasta el punto en que ALTER TABLE [dbo].[T2] NOCHECK CONSTRAINT [FK_T2_T1]se emite un.

Las declaraciones, tal como están escritas, básicamente dicen: "Cree esta restricción de clave externa pero no la verifique con los datos existentes. Actívela para cualquier cambio próximo en los datos".

— squillman
fuente

En realidad lo comprobé, no hay diferencia si hay datos incorrectos, la primera o segunda línea no fallará. Para hacer con un solo fallo, tendrían que verse así:

— Delux el

2

ALTER TABLE [dbo]. [T2] CON CHECK CHECK CONSTRAINT [FK_T2_T1]

— Delux

Correcto. Pero verá que falla después de eso cuando en algún momento intente ejecutar un INSERT o una ACTUALIZACIÓN que viole la restricción. Ninguno fallará si existen datos incorrectos en el momento en que se ejecutan esas 2 declaraciones.

— Squillman

7

Su primera declaración crea una restricción deshabilitada. Necesita ser habilitado y posiblemente confiable. La siguiente sintaxis extraña asegurará que su restricción esté habilitada y confiable:

ALTER TABLE YourTable
      WITH CHECK CHECK CONSTRAINT YourConstraint;

Hay una muy buena publicación de blog de Hugo Kornelis que lo explica en detalle: ¿Puedes confiar en tus limitaciones?

— Alaska
fuente