Unable to "turn off" some table trigger code

grand_national

Member
Forgive me for posting to multiple forums.
Maybe the CNC forum is more appropriate since I now have more information about this issue.

JDE: 9.1, TR 9.1.3, SS DB
===================
We needed a table trigger to insert into a log table.
The TER code was changed.
The change was built and deployed.
Everything worked as expected.
--
We now want to turn off that table trigger insert.
The TER code was commented out.
The change was built and deployed.
*Except, the table trigger is still now in place; inserts still occurring into log table.
--
We noticed on the initial implementation of the trigger code, the jdbtrg2.dll file was updated in the pathcode folder on the enterprise server.
Our recent change to comment out the trigger code, did not update this file.
--
We did not do the initial build and deployment ourselves, so we are 100% familiar with the process which was used.
--
[update: Oracle has acknowledged a bug] ( Doc ID 2120700.1 ) Bug 18163361

This is what is provided:

Workaround

Run a manual generation of the table followed by a clear cache of the serialized objects in server manager.

The table with the trigger is fully populated with data.
Gen'ing the table to clear the table which I don't want to do.
If the problem is with the serialized object code, when couldn't we just serialize that TER code?
If so, how would we do that differently from doing our normal package build of the table object, which doesn't work?


--
Thanks in advance for all help on this.
 
I believe when they say "generate" the table they mean generate the serialized objects using the generator tool on the fat client. We see this same issue on a 9.0 install with update packages. You can delete the F989999 records for the table like is shown in the oracle doc. The table will get re-serialized once it's accessed and out of cache.

Craig
 
Jdbtrg2.dll ???

I believe when they say "generate" the table they mean generate the serialized objects using the generator tool on the fat client. We see this same issue on a 9.0 install with update packages. You can delete the F989999 records for the table like is shown in the oracle doc. The table will get re-serialized once it's accessed and out of cache.

Craig

Thank you Craig!

As I understand it..........
The serialization will place the object into the table for the web.
Maybe I'm missing how this process works, but when the trigger was put in place originally built and deployed, the jdbtrg2.dll on the enterprise server was updated.
When we removed the code built and deployed, it was not.

The serialization wouldn't do that aspect though, the build would correct?

The server build did invoke the process to compile the ER, but the DLL wasn't changed on the server when deployed.

What am I missing about this process?
 
There are 2 parts. The compiled code that's in the DLL (TER), and the specs that tell the runtime engine that a trigger exists on the table. Since the serialized objects were not cleared, the runtime still thinks it should execute the trigger. If you query the serialized object tables I bet you find records for the trigger.

As for the DLL not being re-compiled, that's a separate issue but shouldn't present a problem. The code must still exist in the DLL, but once the serialized objects are cleared it will never get called. Building a full package would create a new version of the trigger lib without the functions.

If you have a process that updates the table through a BSFN or UBE, you should now notice the trigger does not fire since the enterprise server reads from the package specs, not the serialized objects.

Craig
 
Isn't there also a JAS server implementation of the table trigger as well that executes on the JAS server for APPL events? Or does the JAS server execute its table trigger action by calling something on the ES server?
 
If the table change (which triggers the trigger) , is happening directly from the JAS server (So think Table IO in FDA ER code) , then the Table Event Rules (TER) will execute on the JAS server it self . This TER code is fetched from the serialized tables.

The bug that exists on the lower tools releases is that the auto generation process which happens after you deploy a package , does not regenerate the TER serialized specs if you made a change to an existing Table Event Rule.

Work around is to perform a manual JAS generation for the table. You need to have a JAS generator machine setup for this (Basically a machine with Web Development setup and then a couple of tweaks to the INI files ).

If you are unable to setup a Generator machine I have used SQL in the past and it has worked for me , but cannot 100% guarantee it will. Hopefully you are doing this in a Non Production environment ?

sample SQL below for DV910 pathcode and table F4311 in a SQL Server Environment. Edit accordingly to your requirements


select * from JDE_DV910.DV910.F989999 WHERE WBOID LIKE 'TER-F4311-%';

then delete accordingly.
 
We are at the same tools release, I noticed that when I do a Client/Server update package. The generator or NERs and TERs does not get run, so the 'C' code doesn't get changed. Oracle has confirmed the issue, but I don't have a bug number. Our workaround is to do a CLIENT ONLY package first. This has the Gen process run on the build machine and moved to the source directory. Then we do a Client/Server build, and all is OK.

Just an idea.
 
This has the Gen process run on the build machine and moved to the source directory. Then we do a Client/Server build, and all is OK.

Are you saying a client-only build runs the 'gen process' on the client and automatically replaces the C code (dll) and then you just do a client/server build following it?
-OR-
Or after the build process, you need to manually move some files? If so, which and from where and to where?

Also, is the 'Gen process' a Trigger Build a JAS Build or a regular package build?

Sorry, I'm not too clear on the terminology or processes involved.
 
I'm saying that client only replaces the C code. And moves it to the parent path code. Then when the server build runs it gets the newly generated code to compile.

I do no manual steps

Tom
 
Back
Top