Re: Triggers for RI extension only

I think the real issue is this:

A "trigger" runs program sequentially, immediately before and/or after the I/O (get or put) operation, and before control returns to the application that initiated the I/O.

If the task requires more than a fairly trivial amount of code, and if it does not absolutely have to be done "in-line" within the actual trigger program, then it is probably a better design to use an asynchronous process to handle this task.

For example (from prior e-mails in this thread), suppose you need to send an e-mail notification to someone. Rather than adding that code inside the trigger program itself, you could create a data queue for "event notification" and the trigger program writes to this data queue some information (presumably from the record being updated that fired the trigger in the first place). Then, you have a pre-scheduled, long-running "server" job that listens to the data queue, and whenever an event arrives, processes it -- in this example, the listener job (program) sends an e-mail to someone to notify them that this "event" has occured.

HTH,

Mark S. Waterbury

> rob@xxxxxxxxx wrote:

...(snip)... But I sure wouldn't limit them to integrity only.

Rob Berendt