Re: Where to put a trigger program...

It does help to be aware that there are triggers.  I was copying some test data into a file and getting a duplicate key error.  I checked the primary key on the target file - no problem.  I checked all the logicals, and only two had unique keys, but again, no problem there either. Turns out it was a trigger program on the target file was adding a record to a completely different file that was getting the duplicate key error.  If I had checked the message details, I would've seen it was caused by a different program, and the file was not directly related to the target file (not immediately apparent - it had a lot of logical files).

--
*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
petercdow@xxxxxxxxx <mailto:petercdow@xxxxxxxxx>
pdow@xxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxx> /

On 3/18/2021 8:58 PM, Robert Rogerson wrote:

Nathan, it's as simple as when data in a table is changed developers look
to application programs for changes to data. It's not that triggers hide
what they are doing. If properly written, a trigger is very clear in when
and why it's doing something. It's just that developers have to look in a
different place for why the change took place.
As I said to Brian I believe triggers solve many issues, but unfortunately
management has a different perspective and unfortunately the IBM i is on
the way out.

Btw, in closing, I summarized what I have learned from the group for
management. The decision was to go with shop standards and create the
external program in PGMLIB.

Thanks to all the advice and recommendations from everyone.

Rob

On Thu, Mar 18, 2021 at 5:09 PM Nathan Andelin <nandelin@xxxxxxxxx> wrote:

On Wed, Mar 17, 2021 at 9:26 PM Robert Rogerson <rogersonra@xxxxxxxxx>
wrote:

Brian, the main reason triggers are frowned on is that things happen in
triggers that aren't readily visible.

By "aren't readily visible", do you mean that the trigger code is in a
separate module? And that your shop prefers in-line code, as opposed to say
modular code? Or do you mean that you might run into trigger logic that may
have been written by someone, which you were not expecting? Whatever the
case, I agree that it can be a big change that developers to get used to.

I mentioned previously that I prefer a pool of database event handlers as
opposed to triggers, which also take some effort to getting used to. But I
weigh that against the benefit of having a place for database related code
such as data validation, RI checks, and business rules that are implemented
via a consistent interface, which entails super modular-consistent-readable
code, which can't be bypassed, unless you temporarily disable it.

Some people call this database-centric architecture as opposed to
application-centric. We count on it to keep our database accurate and
resistant to hacking.
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com