Sie können den folgenden Code verwenden, um alle CHECK zu aktivieren und Fremdschlüsseleinschränkungen für die aktuelle Datenbank in SQL Server.
Wenn Sie einen CHECK aktivieren oder Fremdschlüsseleinschränkung haben Sie die Möglichkeit, vorhandene Daten in der Tabelle zu überprüfen, bevor die Einschränkung aktiviert wird. Auf diese Weise können Sie überprüfen, ob eine vorhandene Einschränkung gegen die Einschränkung verstößt. Um diese Prüfung durchzuführen, verwenden Sie WITH CHECK innerhalb des Codes, ansonsten WITH NOCHECK verwenden .
Beispielcode
So aktivieren Sie alle CHECK und Fremdschlüsseleinschränkungen innerhalb einer Datenbank. Das erste Beispiel prüft vorhandene Daten, das zweite nicht.
Mit Check (empfohlen):
EXEC sp_MSforeachtable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
Ohne Überprüfung:
EXEC sp_MSforeachtable "ALTER TABLE ? WITH NOCHECK CHECK CONSTRAINT ALL"
Sie können den Argumentnamen auch explizit angeben (@command1 ), wenn Sie es vorziehen (Sie erhalten so oder so das gleiche Ergebnis).
Mit Check:
EXEC sp_MSforeachtable @command1="ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
Ohne Überprüfung:
EXEC sp_MSforeachtable @command1="ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
Diese Beispiele verwenden das (undokumentierte) sp_MSforeachtable gespeicherte Prozedur. Mit diesem Verfahren können Sie Aufgaben für jede Tabelle in einer Datenbank ausführen. Es ist also perfekt für unsere Aufgabe hier – alle CHECK zu aktivieren und Fremdschlüsseleinschränkungen innerhalb der aktuellen Datenbank.
Unten ist ein Beispiel, wo ich das mache und dann das Ergebnis überprüfe.
Beispiel 1 – Überprüfen Sie die Einschränkungen
Zuerst werfe ich einen kurzen Blick auf den aktuellen CHECK und Fremdschlüsseleinschränkungen in der Datenbank, um zu sehen, ob sie aktiviert oder deaktiviert sind.
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;
Ergebnis:
+----------------+-----------------+---------------+------------------+ | Table | Constraint | is_disabled | is_not_trusted | |----------------+-----------------+---------------+------------------| | ConstraintTest | chkPrice | 1 | 1 | | ConstraintTest | chkValidEndDate | 1 | 1 | | ConstraintTest | chkTeamSize | 1 | 1 | | Occupation | chkJobTitle | 1 | 1 | +----------------+-----------------+---------------+------------------+
Es gibt also derzeit vier CHECK Einschränkungen Einschränkungen in der Datenbank, für zwei verschiedene Tabellen.
Wir können sehen, dass alle Einschränkungen deaktiviert sind, weil is_disabled auf 1 gesetzt ist .
Außerdem sind sie alle nicht vertrauenswürdig, weil is_not_trusted ebenfalls auf 1 gesetzt .
Beispiel 2 – Aktivieren Sie die Beschränkungen mit WITH CHECK
Jetzt aktiviere ich alle Einschränkungen mit WITH CHECK Argument:
EXEC sp_MSforeachtable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
Es ist immer eine gute Idee sicherzustellen, dass Sie die richtige Datenbank verwenden, wenn Sie solche Dinge tun. Wir könnten also den Code ändern, indem wir zuerst zur richtigen Datenbank wechseln:
USE Test; EXEC sp_MSforeachtable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
In diesem Fall wechsle ich zu einer Datenbank namens Test bevor die gespeicherte Prozedur ausgeführt wird.
Beispiel 3 – Überprüfen Sie das Ergebnis
Nachdem ich den obigen Code ausgeführt habe, führe ich jetzt dieselbe Abfrage aus dem ersten Beispiel aus, um das Ergebnis anzuzeigen.
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;
Ergebnis:
+----------------+-----------------+---------------+------------------+ | Table | Constraint | is_disabled | is_not_trusted | |----------------+-----------------+---------------+------------------| | ConstraintTest | chkPrice | 0 | 0 | | ConstraintTest | chkValidEndDate | 0 | 0 | | ConstraintTest | chkTeamSize | 0 | 0 | | Occupation | chkJobTitle | 0 | 0 | +----------------+-----------------+---------------+------------------+
Somit sind jetzt alle Beschränkungen in der Datenbank aktiviert (weil die is_disabled Spalte ist auf 0 gesetzt für alle Beschränkungen).
Wir können auch sehen, dass is_not_trusted ist Spalte wird ebenfalls auf 0 gesetzt . Dies bedeutet, dass der Einschränkung vertraut wird. Es ist vertrauenswürdig, weil wir es dazu gebracht haben, alle vorhandenen Daten zu überprüfen, bevor es aktiviert wird.
Wenn ich WITH NOCHECK verwendet hätte , würden die Einschränkungen nicht vertrauenswürdig bleiben (d. h. ihre
is_not_trusted
Flag würde auf
1
gesetzt werden ). Dies liegt daran, dass die Datenbank möglicherweise Daten enthalten könnte, die gegen eine (oder mehrere) der Einschränkungen verstoßen (ungültige Daten könnten in die Datenbank gelangt sein, während die Einschränkungen deaktiviert waren).
In seltenen Fällen müssen Sie möglicherweise ungültige Daten in der Datenbank behalten. In solchen Fällen muss die Einschränkung nicht vertrauenswürdig bleiben, da die vorhandenen Daten die anfängliche Prüfung nicht bestehen würden und die Einschränkung daher nicht aktiviert werden könnte, es sei denn, sie verwendet WITH NOCHECK .
Unter What You Should Know about WITH NOCHECK when Enabling a CHECK Constraint in SQL Server finden Sie ein detailliertes Beispiel für den Wechsel zwischen vertrauenswürdig und nicht vertrauenswürdig beim Deaktivieren und erneuten Aktivieren einer Einschränkung.
Aktivieren Sie die Beschränkungen einzeln
Wenn Sie die Einschränkungen nur einzeln aktivieren möchten, lesen Sie So aktivieren Sie eine CHECK-Einschränkung in SQL Server und So aktivieren Sie einen Fremdschlüssel in SQL Server.
