Constraints can only take effect after they have been checked. This means that you must run the constraint checker after you have defined a constraint. The constraint checker validates the syntax of the constraint, as well as the existence of the objects referred to in the constraint. For integrity reasons, constraints are also checked when a constraint is read from the repository at run time.
If there are any syntax errors in the constraint you are having checked, the Rules Engine displays a message. In the message, an asterisk (*) indicates the position of the syntax error.
If a constraint check is successful, in the Constraints or Domain Constraints window, the Correct attribute will be checked. If you subsequently edit the constraint, this attribute is automatically cleared so you must re-check the constraint.
After a constraint has been checked, there are a couple of repository tables that are filled with information about the tables, columns, and relationships that are used in the SQL statement of the constraint. These repository tables are called SQL Object tables. You cannot influence constraint handling via these tables, because constraint evaluation is handled internally.
Constraints that do not have the Correct attribute checked are ignored at run time.