Jones Simon wrote:
A requirement has come up where some of the processing which is done by
the trigger program will need some user input by way of an interactive
screen. Instead of adding this screen to the trigger program I was
looking at adding a call to a new program from the trigger program. I'm
trying to work out if this will cause any problems - the trigger program
will be active for the duration of the time that the screen is displayed
and processed.
This just isn't going to work nicely. If the idea behind the trigger
was to handle input from sources other than interactive programs, then
you won't be able to implement it. If the trigger is only for
interactive jobs, then you don't need a trigger, you need business logic.
But, if your adamant about going this route, I'd have the trigger throw
an exception if it needed more data. Batch programs would fall over
dead, but an interactive could call a program to get more data from the
user and then make it available to the trigger.
In general, though, any code that needs to talk interactively to the
user shouldn't be in a trigger.
My initial thoughts are that this is likely to be a bad idea, but I'm
not really sure why!
You were right!
Hopefully I've made that clear
Me too.
Joe
