SQL Server Comprobar/NoCheck diferencia en scripts generados

Estoy tratando de sincronizar los esquemas entre diferentes bases de datos. Básicamente, ejecuté tareas-> Generar scripts con SQL Server Management Studio (2005) en ambas bases de datos y estoy comparando el resultado con una herramienta diff.SQL Server Comprobar/NoCheck diferencia en scripts generados

Por alguna razón, una secuencia de comandos agrega la restricción WITH CHECK y uno sin verificación de, seguido por ambas limitaciones de ser re-habilitado.

I para la primera base de datos me sale:

ALTER TABLE [dbo].[Profile] WITH CHECK ADD CONSTRAINT [FK_Profile_OrganizationID] FOREIGN KEY([OrganizationID]) 
REFERENCES [dbo].[Organization] ([OrganizationID]) 
GO 
ALTER TABLE [dbo].[Profile] CHECK CONSTRAINT [FK_Profile_OrganizationID] 
GO

La segunda base de datos genera como

ALTER TABLE [dbo].[Profile] WITH NOCHECK ADD CONSTRAINT [FK_Profile_OrganizationID] FOREIGN KEY([OrganizationID]) 
REFERENCES [dbo].[Organization] ([OrganizationID]) 
GO 
ALTER TABLE [dbo].[Profile] CHECK CONSTRAINT [FK_Profile_OrganizationID] 
GO

Así que tengo dos preguntas:

es resultado final de la misma ? (Editar: Parece que una gran cantidad de personas están recogiendo únicamente en la primera declaración de los dos guiones Estoy interesado en el resultado final de la totalidad de los dos guiones..)
Si el final el resultado es el mismo, ¿por qué Management Studio los genera de manera diferente para diferentes bases de datos?

Fuente

2009-08-26 Nathan

¡El resultado final no es el mismo!

SQL Server no confiará en la singularidad de FK si no está marcada. Esto significa que se requiere un procesamiento adicional si usa la columna en una consulta.
Para abreviar, es necesario que SQL Server compruebe la columna para que se considere de confianza.

En cuanto a por qué son diferentes de servidores diferentes, compruebe la columna isnottrusted en sys.foreign_keys. Esto puede afectar lo que SSMS está generando?

Para obtener más información acerca de esto, verifique my other answer relacionado con FK & NO HAY opciones de CHEQUEO/VERIFICACIÓN.

Fuente

2009-08-27 02:29:10

Sin embargo, si observa las dos secuencias de comandos, inmediatamente después de agregar la restricción, aparece ALTER TABLE [ dbo]. [Perfil] CHECK CONSTRAINT [FK_Profile_OrganizationID] GO ¿No comprueba eso las restricciones en ese punto? – Nathan

En cuanto a la segunda parte de su respuesta, está en lo cierto al decir que is_not_trusted está establecido en una de las bases de datos, y no en la otra. ¿Qué efecto tiene esto? – Nathan

Encontrado este artículo: http://sqlblog.com/blogs/tibor_karaszi/archive/2008/01/12/non-trusted-constraints.aspx Parece que la segunda declaración en el lote solo asegura que la restricción está habilitada, en realidad, no verifica los datos existentes. Para verificar realmente los datos existentes, ¿necesito ALTERAR LA TABLA? CON CHECK CHECK CONSTRAINT todo – Nathan

Sí que las dos secuencias de comandos son diferentes

WITH CHECK comprobará los datos existentes en contra de la nueva restricción.
CON NOCHECK no verificará los datos existentes con la nueva restricción. Esto le permitirá tener registros secundarios sin un padre correspondiente.

EDIT: cuanto a por qué está haciendo esto SSMS no tengo ni idea

Fuente

2009-08-27 01:28:41 Cory

Sin embargo, si mira las dos secuencias de comandos, inmediatamente después de agregar la restricción, hay ALTER TABLE [dbo]. [Perfil] CHECK CONSTRAINT [FK_Profile_OrganizationID] GO ¿No comprueba eso las restricciones en ese punto? – Nathan

Ambos son servidores SQL Server 2005? Como el resultado es el mismo, la herramienta de generación de código puede usar diferentes rutinas basadas en diferentes versiones del producto

Fuente

2009-08-27 01:51:15 Rodrigo

En realidad, en este momento particular, ambas bases de datos están en el mismo servidor, por lo que definitivamente no hay ninguna diferencia de versión de servidor SQL – Nathan

SQL Server Comprobar/NoCheck diferencia en scripts generados

Respuesta

Cuestiones relacionadas