ALLBASE/SQL Reference Manual (36216-90216)

Chapter 4 165
Constraints, Procedures, and Rules
Using Rules
a statement within an invoked procedure which chained another rule), an error will
occur, and the user's statement will be undone.
Changing Session Attributes
Procedures should avoid the following statements, which change the attributes of
transactions or sessions:
• SET CONSTRAINTS
• DISABLE RULES
• ENABLE RULES
• SET PRINTRULES
• SET USER TIMEOUT
If you include one of these statements in a procedure invoked by a rule, consider its effect
carefully. If any of these statements is executed by a procedure invoked by a rule, and it
causes the setting of the attribute to change, then the user's statement will execute partly
in the original mode and partly in the altered mode. In the event of rule chaining,
attributes might change several times. If a statement that invokes a procedure is undone,
any settings modified by the procedure are restored to their values prior to the issuing of
the statement.
The SET CONSTRAINTS statement will change the application of check constraints as of the
next statement in the procedure, and this change will affect the remainder of the set of
rows defined by the triggering statement. The SET CONSTRAINTS statement will change
the application of unique and referential constraints as of the user's next statement--that
is, the statement following the one that invoked the procedure through a rule.
The DISABLE RULES statement will have no effect on the firing of the rules on their
respective current rows. It will only affect rows not yet checked and rules not yet fired.
DISABLE RULES can be used to ensure that the rule depth of 20 is not exceeded, if the chain
of rule dependencies is understood well enough for the appropriate placement of this
statement.
SET PRINTRULES ON and SET PRINTRULES OFF affect the printing of rule names of rules
not yet fired, or of rows not yet checked.
Performance Considerations
The placement of conditions on execution of statements within the firing of a rule should
be examined carefully. Firing conditions placed in the WHERE clause can avoid the
overhead of loading and invoking the procedure, since the WHERE condition is checked
before the procedure is invoked. Thus, it might be better to develop several rules with
separate conditions and procedures with well-defined actions rather than a single rule
with no condition and a single procedure that makes checks before deciding what steps to
carry out. To determine the best design for your needs, weigh the overhead of frequent
loading and executing of a procedure against the overhead of maintaining several
procedures and rules.