RE: ALL I/O in single module was(ARGH!!! (was file open with LR))

Rob,
 
We'll just have to disagree here. I think she is
speaking of using triggers in general and not just
from a 5250 perspective and makes it quite clear in
the article what her position regarding the proper use
of triggers is. Specifically, she says that ...

"Triggers are ideally suited for implementing business
logic that's independent of the user interface and
directly related to database maintenance functions." 

and 

"[Using triggers for data validation] is contrary to
the essential philosophy of triggers, which assumes
that a trigger may be launched from any application
and that the application writer may not even be aware
that a trigger is associated with a particular
database event."

I think the key phrases in that last sentence is 
"essential philosophy of triggers". Yes, she does
acknowledge that people can and do use triggers for
data validation but she points out that this creates
potential pitfalls and additional work for the
developers and that it goes against her idea of the
intended use of triggers.

Regards,
Jake


--- rob@xxxxxxxxx wrote:

> That's a concern.  The problem is that many writers
> of trigger programs 
> tend to 'ass-u-me' that all executions of the
> trigger are going to come 
> from the same 5250 program they were doing
> maintenance from in the first 
> place.  Thus they tailor it to interact only in that
> environment.  Like 
> certain methods of message handling.  However if you
> do something generic 
> like send an escape message then it will be the job
> of whatever program 
> that did the update to trap for that.  And this
> should be able to occur 
> regardless of your environment:  custom 5250,
> UPDDTA, odbc, JSP's, etc.
> 
> I truly believe that this is what was being
> addressed in the article you 
> quote.
> 
> Rob Berendt

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree