Pro2 4.6 - Forum - OpenEdge Pro2 - Progress Community
 Forum

Pro2 4.6

This question is answered

I inserted a trigger and the trigger is not working.  How can I see if the trigger is truly activated?

HP-UX 11.31

OE 11.4

Target SQL database.

Thanks in advance!

Verified Answer
  • Sounds like you have checked everything on the Pro2 side.  If the TableXref.genQRec flag is true, and the triggers are properly inserted, you should be seeing replqueue records.   My suggestion is to verify the trigger is actually running.  Maybe open and close a file within the trigger code.  Did you see the file get created?  Be careful of doing this in a production environment.  If the table in question is heavily transacted, the opening/closing of an OS level file could really slow down the application.

    Another thing to check would be if the the application uses SCHEMA CACHE files (-cache <filename> client side startup parameter.)  If -cache in play then I would suggest this is your issue.  Simply inserting triggers and pointing to an old cache file would allow the user session to not even recognize a trigger has been inserted.   If this is the case,  you'll need to generate a new cache file (search the docs for SAVE-CACHE) and then distribute the new file to the application.  

    Terry Mays

  • Glad that worked for you.

All Replies
  • First check that triggers really inserted.

    For this use ReplTrigDisp.p program from Pro2 distribution.

    Or go to Data Dictionary and check report Database -> Reports -> Trigger.

  • I did all of that - I can see the trigger in the Dictionary report, and I can Display the trigger with the ABL program.  I also tested the trigger in a test env and the trigger fires.  

  • What you mean when says that "the trigger is not working"? Records are not created in the repl queue? No errors when the application is running?

  • yes, nothing in the queue and with no errors.  I recompiled all the our ERP code and still not working.

  • Maybe  the GenQRec flag  cleared for tables in the replication map?

    Check in the database "repl" for specific table:

    FIND FIRST ReplTableXRef WHERE

                 ReplTableXRef.SrcDB    = <source-db-name> AND

                 ReplTableXRef.SrcTable = <source-table-name> NO-LOCK NO-ERROR.

    IF AVAILABLE ReplTableXRef AND ReplTableXRef.GenQRec THEN

    DISPL ReplTableXRef.SrcTable

               ReplTableXRef.GenQRec

               ReplTableXRef.ProcQRec.

    GenQRec and ProcQRec should be TRUE.

  • I check that too

    here is the output

                    Gen   Proc

    Source Table     Queue Queue

    ──────────────── ───── ─────

    bpel             Y     Y

  • Hi,

    Please verify that the repl_d and repl_w folder contents(where trigger is getting created) is placed in the right folder and it is getting executed from there.

    Regards,

    Kunal

  • I did that too - what is odd is that I added 3 tables to replication and 2 out of the three tables are working. I checked all the code to make sure the table is not getting disable with the allow-replication and its all good.

  • As you said, you have added 3 tables out of which 2 tables are working and the third one is not working.

    So, the table which is not working -

    Please verify that it is correctly mapped and as per valeriy- run the same query for that table and let us know if it is still not working.

    Regards,

    Kunal

  • Sounds like you have checked everything on the Pro2 side.  If the TableXref.genQRec flag is true, and the triggers are properly inserted, you should be seeing replqueue records.   My suggestion is to verify the trigger is actually running.  Maybe open and close a file within the trigger code.  Did you see the file get created?  Be careful of doing this in a production environment.  If the table in question is heavily transacted, the opening/closing of an OS level file could really slow down the application.

    Another thing to check would be if the the application uses SCHEMA CACHE files (-cache <filename> client side startup parameter.)  If -cache in play then I would suggest this is your issue.  Simply inserting triggers and pointing to an old cache file would allow the user session to not even recognize a trigger has been inserted.   If this is the case,  you'll need to generate a new cache file (search the docs for SAVE-CACHE) and then distribute the new file to the application.  

    Terry Mays

  • Also, make sure that the refresh interval is minimal and please verify whether replqueue record is getting created in the backend or not?

    This query will give you the list of queue records for which table is not working.

    For each replqueue where replqueue.srcdb = <src-db-name>

                                        and replqueue.srctable - <table name which is not working> no-lock:

    disp replqueue except rawdata.

    end.

    Check, whether record is available or not? May be the case it is getting created in the backend but not displayed in front end GUI.

  • If two of three tables are working, then my suggestion on -cache is not your issue.  Are you running compression triggers?  If so, do you have an old un-applied queue record for the same table/rowid combination?  If yes then you would not see a new entry show up, the trigger would simply update the un-applied queue record and not create a new one.

    Terry

  • it is - I even deleted, re-mapped, and re pulled the table.  

  • oh wow that could be it - I forgot about the cache.  I will recompile the cache and let you know.

  • that was it - Thank you! Thank you!