Kbase 20571: How to Programmatically Override a 4GL Schema Trigger.
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
2/22/2006 |
|
Status: Unverified
GOAL:
How to override the database schema triggers in order to implement some alternative business logic.
FIX:
An override of a database schema trigger involves the definition of the target schema trigger as overridable and the writing of a database event session trigger to override the database schema trigger.
The following example overrides the DELETE schema trigger defined for the Customer table in the sample Sports2000 database. Follow these steps:
1) Using the Data Dictionary:
a) Connect to the sports database.
b) Choose table properties.
c) Choose triggers.
d) Choose the DELETE trigger you want to override.
e) Check the OVERRIDABLE toggle box.
f) Close the data dictionary and save your changes.
2) In your application, define your session trigger that implements your alternative business logic as needed.
This example only prevents the schema trigger from firing and quietly deletes a customer record:
ON DELETE OF Customer OVERRIDE
DO:
/* Session trigger alternative code */
/* implementing new business logic. */
/* In our case we are doing nothing */
/* more than suppressing the schema trigger */
END. /* end of session trigger */
/* Find a Customer record you want to delete */
FIND FIRST Customer.
DELETE Customer.
Trigger scope:
The scope of a trigger is that part of the application during
which the trigger can be executed.
The scope of a database event runtime trigger is the nearest
containing procedure, sub-procedure or trigger block in which it
is defined.
Thus, the DELETE OF customer trigger as defined above remains in
effect until another ON statement defines another trigger for the
same DELETE OF customer database event, either in the same
procedure or another procedure or sub-procedure.
If a sub-procedure or a trigger block of the main procedure
defines another DELETE OF customer session trigger, the new
session trigger is in effect (only) within the defining sub-
procedure or trigger block. When control reverts to the main
procedure, the initial ON DELETE of customer trigger is once
again in effect.