Se hai un CHECK vincolo in SQL Server che è attualmente disabilitato, puoi utilizzare il codice seguente per riattivarlo.
Quando abiliti un CHECK vincolo (o un vincolo di chiave esterna per quella materia), hai la possibilità di specificare se controllare o meno i dati esistenti nella tabella.
Di seguito sono riportati esempi di codice per abilitare un CHECK vincolo, specificando ciascuna di queste diverse opzioni.
Esempio 1:abilitare un vincolo utilizzando WITH CHECK
Questo è il metodo consigliato per abilitare il tuo CHECK vincoli (a meno che tu non abbia un motivo specifico per non usarlo).
Ecco un esempio di abilitazione di un vincolo chiamato chkJobTitle :
ALTER TABLE Occupation WITH CHECK CHECK CONSTRAINT chkJobTitle;
Qui dichiaro esplicitamente WITH CHECK , che indica a SQL Server di controllare i dati esistenti prima di abilitare il vincolo. Se qualche dato viola il vincolo, il vincolo non verrà abilitato e riceverai un errore.
Questo è positivo, perché rafforza l'integrità dei dati.
Quando crei un nuovo CHECK vincolo, questa è l'impostazione predefinita. Tuttavia, quando abiliti un vincolo esistente (come stiamo facendo qui), non lo è l'impostazione predefinita.
Esempio 2:abilitare un vincolo utilizzando WITH NOCHECK
In questo esempio il vincolo è abilitato senza controllare i dati esistenti:
ALTER TABLE Occupation WITH NOCHECK CHECK CONSTRAINT chkJobTitle;
Qui dichiaro esplicitamente WITH NOCHECK , che indica a SQL Server di non controllare i dati esistenti. Ciò significa che il vincolo sarà abilitato anche se la tabella contiene già dati che violano il vincolo.
Questa è l'impostazione predefinita quando si abilita un vincolo (ma non durante la creazione).
Uno dei pochi motivi (probabilmente l'unico motivo) per utilizzare questo è se si desidera mantenere dati non validi nel database. Forse hai un'eccezione una tantum in cui devi inserire una riga o più di dati non validi, ma hai bisogno che tutti i dati futuri siano conformi al vincolo.
Tuttavia, ci sono ancora dei rischi associati a questa operazione. Ecco cosa ha da dire Microsoft al riguardo:
Non consigliamo di farlo, tranne in rari casi. Il nuovo vincolo viene valutato in tutti gli aggiornamenti dei dati successivi. Eventuali violazioni dei vincoli soppresse da WITH NOCHECK quando viene aggiunto il vincolo potrebbe causare il fallimento degli aggiornamenti futuri se aggiornano le righe con dati che non seguono il vincolo.
Quindi usando WITH NOCHECK potrebbe causare problemi in seguito.
Esempio 3:abilitare un vincolo utilizzando l'opzione predefinita
Ecco un esempio che utilizza l'opzione predefinita:
ALTER TABLE Occupation CHECK CONSTRAINT chkJobTitle;
Questo esempio è l'equivalente dell'esempio precedente. Poiché non ho specificato se controllare o meno, SQL Server presume che io voglia WITH NOCHECK .
L'uso di CON NOCHECK rimuove la fiducia
Quando abiliti un vincolo usando WITH NOCHECK , una conseguenza di cui dovresti essere a conoscenza è che SQL Server non si fida più di tale vincolo. Lo contrassegna come non attendibile.
Sì, avete letto bene. In realtà c'è un is_not_trusted flag che SQL Server imposta su 1 quando disabiliti un CHECK vincolo (il che significa che non è attendibile) e l'unico modo per impostarlo su 0 (attendibile) è specificare WITH CHECK quando si riattiva il vincolo. Usando WITH NOCHECK semplicemente non lo taglia.
Questo ha perfettamente senso. Dopotutto, vorresti tu ti fidi di un vincolo che non ha verificato tutti i dati?
Usando WITH CHECK , ti assicuri che il vincolo controlli tutti i dati esistenti prima di essere abilitato. L'unico modo in cui può essere abilitato è se tutti i dati esistenti sono conformi al vincolo. Dopo aver verificato tutti i dati esistenti, può essere considerato affidabile.
Per ulteriori informazioni, vedere Cosa dovresti sapere CON NOCHECK quando si abilita un vincolo CHECK in SQL Server, dove puoi vedere l'effettivo is_not_trusted il flag viene alternato avanti e indietro ogni volta che disabilito e riabilito un CHECK vincolo.
