Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Trigger?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Trigger?

    Try this link: http://www.martinvt.com/Code_Samples...r/trigger.html

  • #2
    Trigger?

    Let me know and I will send you a working example. You can email me at kevin.forsythe@dmcconsulting.com

    Comment


    • #3
      Trigger?

      Look in the RPG Redbook. You can find a link to it at http://faq.midrange.com --buck

      Comment


      • #4
        Trigger?

        Thank all, for replying.. I've gone through the "Who Knew You Could do That With RPG IV?". I also believe I've found complete working source codes on the net. The funny thing is, I'm not sure what the sample supposed to do. No explaination. Just codes. Do I need to do something to the database? How? What is the result supposed to be? It's like getting a car without knowing how to drive it. Regards

        Comment


        • #5
          Trigger?

          Use the ADDPFTRG command to specify what program should be fired by the trigger. You'll say when you want the trigger to fire, *BEFORE, *AFTER, and on what conditions you want it to fire, *INSERT, *DELETE, *UPDATE, *READ. For validity checking, you might want: TRGTIME(*BEFORE) TRGEVENT(*INSERT *UPDATE *DELETE) You can have more than one trigger on the same file with different parameters, like a different one for *BEFORE and *AFTER. The program you specify on the PGM parameter will be the one that gets the buffer images (both before and after if applicable). Beware when copying this file to a development environment, because the trigger will be there after a copy or restore. If the trigger program does something like send a message to a user, x-mit a record to another machine, etc, you could get "unexpected results". Also, make sure you have REALLY good error checking and error handling in your trigger program. Any error there will produce an I/O error in the program that originally issued the update/add/etc. THAT program should carefully monitor all I/O as well. -dan

          Comment


          • #6
            Trigger?

            Hi Dan This is too fast for me.. Let me try to separate it out. Do you mean, there are 4 condition : *INSERT, *DELETE, *UPDATE & *READ. Each can fire 2 types of trigger, *BEFORE & *AFTER. I got some sample that I want to understand : In http://www-1.ibm.com/servers/eserver.../db2/trg01.htm ADDPFTRG is executed with *BEFORE & *UPDATE. Am I correct to say that it mentioned TRG01 to be called before EMPLOYEE file is updated? But at what stage (CHAIN? UPDATE?)? Thanks and regards

            Comment


            • #7
              Trigger?

              You can have[*]before *update
              [*]before *delete
              [*]before *insert
              [*]after *update
              [*]after *delete
              [*]after *insert
              [*]after *read
              So you can up to 7 triggers on any given file. (*before *read would be meaningless) The way to understand when a trigger fires is to understand where it resides. The trigger mechanism becomes part of the PF object itself (you can see trigger info in the output from DSPFD). It doesn't matter if it is a RPG program, SQL or UPDDTA. When the process attempts to update a record, the PF object causes the trigger to be called based on the parameters. So, with *before *update, it will pass the buffer to the trigger program. Only if the trigger program ends with no errors will the record actually be added. Maybe it's not clear in the example (sorry I haven't looked at it...), but the ADDPFTRG is only done to set the trigger up. After that, it's automatic. Your code would never have that in it, unless you are creating the file on the fly. -dan

              Comment


              • #8
                Trigger?

                Here's a example of how a trigger is used. I have a file that is keyed item/warehouse. A user adds a new record because this item is now carried in a 2nd warehouse. But I want the cost brought over from a master file, in dollars local to that warehouse. So I place a trigger on item/warehouse file, *ADD *AFTER. Whenever anyone adds a record to the file, the trigger program executes. The trigger pgm finds the correct cost, and updates the item/warehouse accordingly. I could just as easily specified *ADD *BEFORE, and the lookup would occur just before the database adds the record. Had I specified *UPDATE - it would have executed when a user tried to update the record. The deal is: for each of these conditions, you can have the same pgm execute, or they can all be different pgms. Abd the trigger is enforced whether the update is from RPG, COBOL, SQL, or anything else.

                Comment


                • #9
                  Trigger?

                  TBarstow's example is a good one. Here's a slightly different scenerio. We have one where we used to have DDM files. But if the remote box was down, the application would bomb. So, we added 3 triggers to the file. *BEFORE *DELETE, *AFTER *UPDATE and *AFTER *INSERT, all pointing to the same program. The record is then packaged and sent via SNADS. If the box is down, they just queue up and are sent at the earliest moment. The trigger program just passes along the conditions of the record (*INSERT, *UPDATE, *DELETE), and a program on the remote box processes the record accordingly. -dan

                  Comment


                  • #10
                    Trigger?

                    I'm trying to use a trigger in a way I haven't done before. I want to scan a field for certain characters and replace them, transparently to the program doing the update (and with out modifying all those programs doing the updates). How's the best way to do that? If the trigger program does it (*AFTER, so no record lock), I get a recursive call error. Doing it *BEFORE, and then changing the buffer in the trigger program doesn't seem to affect the actual update. Any ideas? Thanks, -dan

                    Comment


                    • #11
                      Trigger?

                      For *BEFORE, did you specify ALWREPCHG(*YES)? Chris

                      Comment


                      • #12
                        Trigger?

                        Ringer Software - 12:52pm Dec 13, 2004 PST (6.1) For *BEFORE, did you specify ALWREPCHG(*YES)?[*]************* Yes. In research so far, it seems that you can accomplish it two ways. 1 Write the trigger program in C, which allows recursive calls, and further more will tell you the recursion level, so you can drop it on the second pass. 2 You can change the after image in the buffer, and it will put that in the file, but ONLY if you are using commitment control. Since no one could maintain the C program if I wrote it, and since we don't journal, both of these options are not available to me. I have given up and modified the calling programs to do a call before the writes. But if anyone has an idea for this, I'd be interested in the answer for next time. -dan

                        Comment


                        • #13
                          Trigger?

                          Does DFU, CPYF or SQL command also trigger the program?

                          Comment


                          • #14
                            Trigger?

                            Show us the ADDPFTRG commands you used... ALWREPCHG(*YES) on a *BEFORE lets you change the buffer (data) before the insert/update actually takes place (in RPG, it's easy). If it's not working for you, I'd suspect you need a PTF. Chris

                            Comment


                            • #15
                              Trigger?

                              Araman - 04:20pm Dec 13, 2004 PST (6.1.1.1) Does DFU, CPYF or SQL command also trigger the program? Yes.

                              Comment

                              Working...
                              X