Puoi utilizzare il codice qui sotto per abilitare tutti i CHECK e vincoli di chiave esterna per il database corrente in SQL Server.
Quando abiliti un CHECK o vincolo di chiave esterna, hai la possibilità di controllare i dati esistenti nella tabella prima che il vincolo sia abilitato. In questo modo è possibile verificare se qualsiasi esistente viola o meno il vincolo. Per eseguire questo controllo, usa WITH CHECK all'interno del codice, altrimenti usa WITH NOCHECK .
Codice campione
Ecco come abilitare tutti i CHECK e vincoli di chiave esterna all'interno di un database. Il primo esempio verifica i dati esistenti, il secondo no.
Con Check (consigliato):
EXEC sp_MSforeachtable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
Senza assegno:
EXEC sp_MSforeachtable "ALTER TABLE ? WITH NOCHECK CHECK CONSTRAINT ALL"
Puoi anche fornire esplicitamente il nome dell'argomento (@command1 ) se preferisci (otterrai lo stesso risultato in ogni caso).
Con Assegno:
EXEC sp_MSforeachtable @command1="ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
Senza assegno:
EXEC sp_MSforeachtable @command1="ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
Questi esempi utilizzano sp_MSforeachtable (non documentato). procedura memorizzata. Questa procedura consente di eseguire attività su ciascuna tabella in un database. Quindi è perfetto per il nostro compito qui:abilitare tutti i CHECK e vincoli di chiave esterna all'interno del database corrente.
Di seguito è riportato un esempio in cui lo faccio e poi controllo il risultato.
Esempio 1:rivedere i vincoli
Per prima cosa, darò una rapida occhiata all'attuale CHECK e vincoli di chiave esterna nel database, per vedere se sono abilitati o disabilitati.
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;
Risultato:
+----------------+-----------------+---------------+------------------+ | Table | Constraint | is_disabled | is_not_trusted | |----------------+-----------------+---------------+------------------| | ConstraintTest | chkPrice | 1 | 1 | | ConstraintTest | chkValidEndDate | 1 | 1 | | ConstraintTest | chkTeamSize | 1 | 1 | | Occupation | chkJobTitle | 1 | 1 | +----------------+-----------------+---------------+------------------+
Quindi ci sono attualmente quattro CHECK vincoli vincoli nel database, per due tabelle diverse.
Possiamo vedere che tutti i vincoli sono disabilitati, perché is_disabled è impostato su 1 .
Inoltre, sono tutti non attendibili, perché is_not_trusted è anche impostato su 1 .
Esempio 2:abilitare i vincoli utilizzando WITH CHECK
Ora abiliterò tutti i vincoli usando il WITH CHECK argomento:
EXEC sp_MSforeachtable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
È sempre una buona idea assicurarsi di utilizzare il database corretto quando si esegue questo tipo di cose. Quindi potremmo modificare il codice passando prima al database corretto:
USE Test; EXEC sp_MSforeachtable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
In questo caso passo a un database chiamato Test prima di eseguire la procedura memorizzata.
Esempio 3:verifica del risultato
Dopo aver eseguito il codice sopra, ora eseguirò la stessa query del primo esempio per vedere il risultato.
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;
Risultato:
+----------------+-----------------+---------------+------------------+ | Table | Constraint | is_disabled | is_not_trusted | |----------------+-----------------+---------------+------------------| | ConstraintTest | chkPrice | 0 | 0 | | ConstraintTest | chkValidEndDate | 0 | 0 | | ConstraintTest | chkTeamSize | 0 | 0 | | Occupation | chkJobTitle | 0 | 0 | +----------------+-----------------+---------------+------------------+
Quindi tutti i vincoli nel database sono stati ora abilitati (perché is_disabled la colonna è impostata su 0 per tutti i vincoli).
Possiamo anche vedere che è_non_fidato anche la colonna è impostata su 0 . Ciò significa che il vincolo è affidabile. È affidabile, perché è in grado di controllare tutti i dati esistenti prima di essere abilitato.
Se avessi usato WITH NOCHECK , i vincoli rimarrebbero non attendibili (ad es. il loro
non_sicura
flag verrebbe impostato su
1
). Questo perché il database potrebbe potenzialmente contenere dati che violano uno (o più) dei vincoli (i dati non validi potrebbero essere entrati nel database mentre i vincoli erano disabilitati).
In rare occasioni, potrebbe essere necessario mantenere dati non validi nel database. In questi casi, il vincolo dovrà rimanere non attendibile, perché i dati esistenti non supererebbero il controllo iniziale e quindi il vincolo non potrebbe essere abilitato a meno che non utilizzi WITH NOCHECK .
Vedi cosa dovresti sapere CON NOCHECK quando si abilita un vincolo CHECK in SQL Server per un esempio dettagliato del passaggio da attendibile a non attendibile quando si disabilita e riattiva un vincolo.
Abilita i vincoli singolarmente
Se desideri abilitare i vincoli uno per uno, vedi Come abilitare un vincolo CHECK in SQL Server e Come abilitare una chiave esterna in SQL Server.
