Ако трябва да върнете списък с всички CHECK
ограничения, които са били деактивирани в база данни на SQL Server, можете да изпълните T-SQL кода по-долу.
Пример 1 – Връщане само за деактивирани ПРОВЕРКИ Ограничения
Тази заявка връща само деактивирания CHECK
ограничения в текущата база данни. Връща името на ограничението, името на таблицата, към която е приложено, и дефиницията на ограничението.
SELECT OBJECT_NAME(parent_object_id) AS 'Table', name AS 'Constraint', definition FROM sys.check_constraints WHERE is_disabled = 1;
Резултат:
+----------------+-----------------+-------------------------------+ | Table | Constraint | definition | |----------------+-----------------+-------------------------------| | ConstraintTest | chkValidEndDate | ([EndDate]>=[StartDate]) | | Occupation | chkJobTitle | ([JobTitle]<>'Digital Nomad') | +----------------+-----------------+-------------------------------+
Това прави заявка за sys.check_constraints
системен изглед. Знаем, че връща само деактивирани ограничения, защото WHERE
клаузата посочва само редове, които имат is_disabled
колона, зададена на 1
.
Ако искате да върнете всички разрешени CHECK
ограничения, просто променете 1
до 0
.
Пример 2 – Връщане на всички CHECK ограничения
Следната заявка връща всички CHECK
ограничения за текущата база данни (не само за деактивираните). Този път връщам is_disabled
колона, за да демонстрира откъде предишната заявка е получила стойността си:
SELECT OBJECT_NAME(parent_object_id) AS 'Table', name AS 'Constraint', is_disabled, is_not_trusted FROM sys.check_constraints;
Резултат:
+----------------+-----------------+---------------+------------------+ | Table | Constraint | is_disabled | is_not_trusted | |----------------+-----------------+---------------+------------------| | ConstraintTest | chkPrice | 0 | 0 | | ConstraintTest | chkValidEndDate | 1 | 1 | | ConstraintTest | chkTeamSize | 0 | 0 | | Occupation | chkJobTitle | 1 | 1 | +----------------+-----------------+---------------+------------------+
Включих и is_not_trusted
колона в тази заявка. Разумно е да се има предвид тази стойност, тъй като ограничението може да остане ненадеждно дори след като е било повторно активирано. За подробно обсъждане (и примери) на този флаг, вижте Какво трябва да знаете за С NOCHECK, когато активирате ограничение CHECK в SQL Server.