Pro2 4.6

Posted by ctoman on 20-Feb-2018 07:42

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!

Posted by temays on 20-Feb-2018 08:50

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

Posted by temays on 20-Feb-2018 19:38

Glad that worked for you.

All Replies

Posted by Valeriy Bashkatov on 20-Feb-2018 07:53

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.

Posted by ctoman on 20-Feb-2018 07:57

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.  

Posted by Valeriy Bashkatov on 20-Feb-2018 08:14

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?

Posted by ctoman on 20-Feb-2018 08:19

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

Posted by Valeriy Bashkatov on 20-Feb-2018 08:22

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.

Posted by ctoman on 20-Feb-2018 08:25

I check that too

here is the output

                Gen   Proc

Source Table     Queue Queue

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

bpel             Y     Y

Posted by Kunal Berlia on 20-Feb-2018 08:31

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

Posted by ctoman on 20-Feb-2018 08:39

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.

Posted by Kunal Berlia on 20-Feb-2018 08:45

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

Posted by temays on 20-Feb-2018 08:50

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

Posted by Kunal Berlia on 20-Feb-2018 08:52

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.

Posted by temays on 20-Feb-2018 08:53

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

Posted by ctoman on 20-Feb-2018 08:53

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

Posted by ctoman on 20-Feb-2018 09:04

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

Posted by ctoman on 20-Feb-2018 09:15

that was it - Thank you! Thank you!

Posted by temays on 20-Feb-2018 19:38

Glad that worked for you.

Posted by Satya Prasad on 20-Feb-2018 23:28

In case, that table already has replication trigger other than pro2 trigger then “ReplTrigInsert.p” won’t insert the pro2 trigger. Please check the trigger report as Valeriy suggested.
 
Thanks,
Satya
 

This thread is closed