Consultor Eletrônico

Error in Persistent trigger gives NO-APPLY functionality

Persistent triggers behave differently than non-persistent triggers
when an error occurs. This is a design feature provided by Progress.
If you run a persistent trigger and the trigger returns an error then
you automatically get NO-APPLY functionality--which means it behaves
as if the trigger never happened. If the trigger is not persistent
and an error occurs then you do NOT get NO-APPLY functionality.

The reason the persistent trigger was designed this way is because
a persistent trigger can only run an external program. In this
program by itself, you cannot do a return no-apply and have it mean
anything since it is in a context all by itself; therefore,
PROGRESS gives you the no-apply functionality by default when
an error is returned by a persistent trigger. An example of a
persistent trigger is:

ON LEAVE OF handle ANYWHERE PERSISTENT RUN my-validate.

The above example is a persistent trigger because of the PERSISTENT
RUN command. It requires you to run an external procedure-- in this
case, myvalidate. Since myvalidate is an external procedure, the
RETURN NO-APPLY statement embedded in it will not makes sense and
therefore Progress does the RETURN NO-APPLY for you. On the other
hand, with a non-persistent trigger, you have the control to do what-
ever you want to on an error.
You can do RETURN NO-APPLY or not depending on how you want the code
to work. An example of a non-persistent trigger is:
on leave of x anywhere do:
run myvalidate.
if error:error-status then return no-apply. (or whateve ryou want)
end.

Progress Software Technical Support Note # 13741