Just a personal observation, but much of the code I've had to work with over the years never included error handling for file IO. This was always the main deterrent to using constraints, as one needs to trap the error and determine the reason, and handle appropriately... Too many will test for error, but never act upon it. The (e) extender on the file opcodes lets the developer completely ignore error handling altogether! I've learned much on this topic the hardest way possible, being guilty of sloppy work at times... (ahem...) Still, if the program doesn't properly handle errors, then managing I/O via trigger exception will still leave users looking at (and sometimes answering incorrectly) an error screen.
I know this has been covered in newsletters and magazine articles, but I've never seen (that I can recall) a single place for developers to see some "best practice" code samples. I often depend on this list and its archives to help me decide when to find a better tool for the job at hand... Error handlers for IO functions sounds pretty easy, but some (much?) of the sample code in the Information Center is of little help to the newbie.
Rolling in new technologies and coding techniques can cause a lot of frustration in the workplace, especially when it's not well understood by the developers and support staff. This is really a standards and training issue, but management rarely wants to force anyone to step up their game. For the adventurous developer, this usually means a commitment to maintain that code (forever?)... If anyone asks about it, you have to train them, or not. <sigh>
-Eric DeLong
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Wednesday, August 31, 2011 12:34 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Prevent a record from being written using a trigger program.
On 31-Aug-2011 08:40 , Terry Anderson wrote:
We use a third party package to maintain our customer master file.
Corporate has decided to standardize on customer numbers across our
18 divisions. They want a way to prevent the divisions from creating
a customer record that uses a non-sanctioned customer number. I do
not want to modify the third party code if I can help it.
I have used trigger programs in the past to track changes to a file
but is there a way to use one to prevent a record from writing to a
file? If so, does someone have an example of how to do this they
would be willing to share?
In a *BEFORE *INSERT trigger, send a diagnostic message [IMO best
results by sending previous to the program QDBPUT, which will be to the
application requesting the insert\write] and then send an escape message
previous to the trigger program itself [which will be QDBPUT]. The
escape message will cause the database "put" processing to stop, i.e.
preventing the write, and then signal CPF502B to the application program
which requested the write. Assuming no radical changes to the database,
the escape message will not be visible in a trace nor joblog, so what
message [identifier] is used is irrelevant nor should there be any
expectation that the information in that message will be available to
any programs; that is the purpose of the diagnostic. Consider that a
*BEFORE *UPDATE trigger might be required to enforce the same requirements.
Depending on what defines the standardization, a CHECK CONSTRAINT may
be an alternate means to ensure the data being written [and updated]
follows the rules. With more description of the column and data
requirements, and if those requirements might not 'require' a trigger,
someone may be able to provide a check-constraint definition which could
be used instead of the trigger program(s). The I\O error for the failed
write due to a violation of the check-constraint would be the message
CPF502F.
Regards, Chuck
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/rpg400-l.
midrange.com
