Re: Creating a trigger program

I learned that bit of wisdom from earlier discussions on this list. Nice to learn something without having to reinvent the wheel. Creating the same issues untold numbers have already dealt with is not a sign of advanced thinking <g>.

This may be a moot issue, however, as no matter how logical using a trigger sounds, another person - not the sa in this case, is calling the shots. His thinking is a batch job, run once a day, is good enough.

John McKee

-----Original message-----
From: Alan Campin alan0307d@xxxxxxxxx
Date: Wed, 11 May 2011 11:39:38 -0500
To: Midrange Systems Technical Discussion midrange-l@xxxxxxxxxxxx
Subject: Re: Creating a trigger program

<< Besides, if the processing logic was performed inside the trigger itself,
should any change be required in the future, the updater would have to be
stopped to release the lock on the log file. That has been done in the
past, but usually requires advance notice, otherwise a lot of phone calls
start rolling in.>>

Which is why you use a trigger mediator.

On Wed, May 11, 2011 at 9:40 AM, jmmckee <jmmckee@xxxxxxxxxxxxxx> wrote:

-----Original message-----
From: CRPence CRPbottle@xxxxxxxxx
Date: Wed, 11 May 2011 09:40:54 -0500
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Creating a trigger program

On Mon 05-May-2011 19:56 , jmmckee wrote:

We are looking into a process to notify doctors, via email, when one
of their patients has been admitted. When a patient is admitted, a
record is written to a log file. Current idea being tossed around is
to read the log file from the previous day and send emails as needed.
I thought this might be an ideal application for a trigger program.
I could see the trigger getting fired on a write to the log file.
All I would want to do is pass the data to be written to a program
and the program would either send or not send an email. <<SNIP>>

Does business logic dictate that all rows inserted into the log file
should be processed as such [evaluated if, and then to send an e-mail,
based solely on the data in each row], or only dictate that the rows
that this specific application chooses to log should be processed as
such? If the latter, seems to me the trigger may be less appropriate,
especially if the work is just offloaded to be performed asynchronously
[as alluded in other messages is the case] since the trigger would seem
to be adding a level of indirection with little benefit. Obviously
there may be other reasons for which the logic must be or is better
performed outside the existing application; i.e. no capability, or
otherwise undesirable for whatever reason(s), to modify the application
itself.

Regards, Chuck
--

The log file is likely the easiest approach. The log file is written to as
part of processing by an updater program. That is a nasty program to
modify. Do-able, but nasty. Not all records written to the log file would
be used for sending email. Processing would require reading perhaps six
other files. Seemed better to have the trigger program submit a job and not
slow things down. The submitted job would not run long. But, the
processing, if done within the trigger, might not be acceptable. Besides,
if the processing logic was performed inside the trigger itself, should any
change be required in the future, the updater would have to be stopped to
release the lock on the log file. That has been done in the past, but
usually requires advance notice, otherwise a lot of phone calls start
rolling in.

John McKee
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.