Trigger Question

[Guest.Visitor]

I haven't worked on trigger programs in years and have a question. We have a (*UPDATE *BEFORE) trigger over a file. Trigger condition is *Always allow repeated change = No. The trigger program is an RPGLE type dftactgrp(*no) actgrp(*caller) and we are running V5R4.

I have a field that should be updated by the trigger but isn't. I can update the field with any value and in debug can watch the code change the value to the correct value but once the program exits the value in the file exists just as if the trigger had never fired. Any ideas of why the field isn't being updated?

When I run it thru debug I choose Update Production Files *Yes.

[D.Abramowitz]

Have you tried compiling the trigger as DFTACTGRP(*YES)?

Dave

[efnkay]

Mr. Abramowitz' suggestions plus a few others to consider about trigger programs: Good Luck!

Recommendations for trigger programs:
Consider these recommendations when you create a trigger program.

Create the trigger program so that it runs under the user profile of the user who created it. In this way, users who do not have the same level of authority to the program will not encounter errors.

Create the program with USRPRF(*OWNER) and *EXCLUDE public authority, and do not grant authorities to the trigger program to USER(*PUBLIC). Avoid having the trigger program altered or replaced by other users. The database calls the trigger program even if the user causing the trigger program to run does not have authority to the trigger program.

Create the program as ACTGRP(*CALLER) if the program is running in an Integrated Language Environment® (ILE). This allows the trigger program to run under the same commitment definition as the application.
Open the file with a commit lock level the same as the application's commit lock level. This allows the trigger program to run under the same commit lock level as the application.

Create the program in the physical file's library.

Use commit or rollback in the trigger program if the trigger program runs under a different activation group than the application.

Signal an exception if an error occurs or is detected in the trigger program. If an error message is not signalled from the trigger program, the database assumes that the trigger ran successfully. This might cause the user data to end up in an inconsistent state.

[pradeepsethi]

Trigger Question

For what you are trying to do Allow Repeated Changes keyword ALWREPCHG should be set to *YES and your program should be running under commitment control.

[Guest.Visitor]

Thanks, allow repeated change = Yes fixed it.

The following is from ibm...

The Allow Repeated Change ALWREPCHG(*YES) parameter on the Add Physical File Trigger (ADDPFTRG) command also affects trigger programs defined to be called before insert and update database operations. If the trigger program updates the new record in the trigger buffer and ALWREPCHG(*YES) is specified, the actual insert or update operation on the associated physical file uses the modified new record image. This option can be helpful in trigger programs that are designed for data validation and data correction. Because the trigger program receives physical file record images (even for logical files), the trigger program may change any field of that record image.

[pradeepsethi]

happy to help.

[Guest.Visitor]

Hi rpgflunkie,

In this case while adding Trigger on Physical file by the help of Command ADDPFTRG.There is one Parameter Trigger update condition (TRGUPDCND) default value *ALWAYS has been used that means The trigger program is called whenever a record is updated, whether or not a value changes.