ALLBASE/SQL Reference Manual (36216-90216)

Chapter 4 163
Constraints, Procedures, and Rules
Using Rules
statement is also undone.
In application programs, you use SQLEXPLAIN to retrieve the messages generated by RAISE
ERROR and other SQL statements.
Enabling and Disabling Rules
Rule processing takes place by default in the DBEnvironment. However, the DBA can use
the following statement to disable the operation of rules in the current session:
isql=> disable rules;
This statement, which is useful in debugging, should be employed only with great care,
since it can affect the integrity of the database, if rules are being used to control data
integrity. To restore the operation of rules in the session, use the following statement:
isql=> enable rules;
Rules are not fired retroactively when the ENABLE RULES statement is issued after the
DISABLE RULES statement has been issued.
Special Considerations for Procedures Invoked by Rules
Procedures operate somewhat differently when invoked by rules than when invoked
directly by a user. The differences are most pronounced in several areas:
Transaction handling.
Effects of rule chaining.
Invalidation of sections.
Changing session attributes.
Performance considerations.
Transaction Handling in Rules
Since rules are fired by data manipulation statements that are already being executed, a
transaction is always active when a rule invokes a procedure. Therefore, BEGIN WORK and
BEGIN ARCHIVE statements will result in errors in a procedure invoked by a rule. The error
will cause the rule to fail and the user's statement to be undone.
COMMIT WORK, COMMIT ARCHIVE, ROLLBACK WORK, ROLLBACK ARCHIVE, SAVEPOINT, and
ROLLBACK TO SAVEPOINT statements will generate errors when encountered in procedures
triggered by rules. The error causes the user's statement and all subsequent rule-driven
statements to be undone. If you wish to include COMMIT WORK, COMMIT ARCHIVE,
ROLLBACK WORK, ROLLBACK ARCHIVE, SAVEPOINT, or ROLLBACK TO SAVEPOINT
statements in the procedure, because the procedure will be executed by users directly as
well as by rules, you should include these statements within a condition that will only be
true for non-rule invocation. To do this, add a flag parameter to the procedure. Have users
invoking the procedure pass in a fixed value (such as 0), and have rules invoking the
procedure pass in a different value (such as 1).