I might be missing something but it seems to me that integrity in the
context it was used might be referring to something more than just plain old
record relationships.
If you want "something" to happen *every* time something is done to a record
in a table then a trigger is at least one obvious answer.
Tying the code to an event in the database rather than the entry program
extends the integrity of the application because no matter how the record is
touched, the action in the trigger is executed.
If the action is contained in a program or other interface that can be
by-passed then the application has somewhat less integrity - it can't
guarantee unconditionally that the requested action will be performed when
the database event occurs.
Maybe it's a case semantics, but I can see what Simon is driving at.
Regards
Evan Harris
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of James Lampert
Sent: Thursday, 12 June 2008 4:29 a.m.
To: RPG programming on the AS400 / iSeries
Subject: Re: Triggers for RI extension only
rob@xxxxxxxxx wrote:
But I sure wouldn't limit them to integrity only.
Hear, hear!
Triggers are the correct answer WHENEVER you need some action to be
taken BASED ON FILE DATA BEING MODIFIED, WITHOUT REGARD TO HOW, WHY, OR
WITH WHAT PROGRAM.
Building your side effect into the application (or more likely, into
some exit program called by your application) blatantly ignores the very
real possibility that some other application (or utility) might modify
the data. It also blatantly ignores the fact that even the OS/400 world
is a world of commodity software, in which (for most installations)
having even a minor customization added to a canned application will
frequently cost more than the application itself.
Simon's dogmatic pontification on this subject reminds me of all the
knockdown-dragout food fights over The Cycle.
As an Amazon Associate we earn from qualifying purchases.