• Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

E1 Table Trigger

nkuebelbeck

VIP Member
I'm attempting to create my first E1 trigger on a stock object. I've created the ER code and built the trigger(no build errors). Fxxxx.c and Fxxxx.h are both out there and I can see my ER code converted to C.

Now when I update/insert a record using the jde stock application run on my localweb, it's not running my db trigger.

The trigger is looking for a certain value during updating/inserting events and updating/inserting into another custom table. The custom table is on my fat client only, hasn't been deployed. It has been generated.

I've even hooked up the visual studio debugger to the active console process and my event isn't firing in VS either.

Any help would be much appreciated

Thanks
 

Chan Rana

Legendary Poster
Possible that HTML spec might be missing locally for trigger. Do a generate HTML on your fat client for the table and try if that works.

If this doesn't fix then you might want to run DBTemplate.exe utility which we run after each refresh to fix RTE triggers. You can run it on local datasource to regenerate triggers on table. This should normally fix the issue.

Thanks,
Chan
 

BOster

Legendary Poster
You might try and do a manual Java Gen on the table object. I have found that for some changes the "auto java gen" doesn't always happen.

Additionally, I find that these guidelines will help when working with JDE table triggers:

1. Stay away from table triggers if at all possible, only use them as a last resort.
2. If you really feel like you need a table trigger avoid JDE Table triggers at all costs. Instead use a DB table trigger.
3. If you still really, really, really feel like you need an JDE table trigger see #2.
 

craig_welton

Legendary Poster
I had to change this jdbj.ini value to get some triggers to work from an app. This was on an older TR, so just a stab. Default is false

; Trigger auto fetch property. Indicates whether JDBj should
; automatically fetch rows to be changed in order to pass them
; to OneWorld triggers. This is needed for certain triggers to
; work properly.
;
; Valid values: true, false

triggerAutoFetch=true


Craig
 

nkuebelbeck

VIP Member
You might try and do a manual Java Gen on the table object. I have found that for some changes the "auto java gen" doesn't always happen.

Additionally, I find that these guidelines will help when working with JDE table triggers:

1. Stay away from table triggers if at all possible, only use them as a last resort.
2. If you really feel like you need a table trigger avoid JDE Table triggers at all costs. Instead use a DB table trigger.
3. If you still really, really, really feel like you need an JDE table trigger see #2.
How does one "Java Gen on the table object"

Why the dislike of jde table triggers? jde documentation warns of native db triggers

E1: TDA: Frequently Asked Questions on Table Triggers (Doc ID 1552330.1)

"Question 3: Are native database triggers supported with EnterpriseOne?

Answer 3: No. Native database triggers are not supported on EnterpriseOne tables. They can cause EnterpriseOne applications to fail unless the database triggers are removed. It is the responsibility of the DB Administrator to investigate should customer decide to add database triggers to EnterpriseOne tables. Review Question 3: SQL Server Native Database Triggers in Document 1529603.1 E1:DB: Frequently Asked Questions on SQL Server Features Support."
 

jdelisths

Reputable Poster
Try closing out of E1 and deleting the glbltbl.* tables in your path code folder (c:\E910\dv910 for example)
 

BOster

Legendary Poster
Why the dislike of jde table triggers? jde documentation warns of native db triggers
We tried using JDE table triggers in the past and got burned by them because, quite frankly, they were broken. We implemented the same solution(s) with DB triggers and all worked great, because databases are generally good at doing database things.

They may be better now. In fact some of the parameters that Craig eluded to (triggerAutoFetch) I believe were an attempt to fix them. The problem used to be (again maybe not anymore) that if application A did a fetch on a record before updating it and application B just did the update the trigger would work for application A and not for application B. This is because the fetch was needed to fill out the primary key values used by the table trigger. This resulted in inconsistent behavior of JDE table triggers depending on which application initiated the table I/O. I think the triggerAutoFetch was supposed to solve this. However I don't think it solved the issue where you have an update or delete statement that updated multiple records with one SQL statement. JDE table triggers (as opposed to DB triggers) also don't account for non-JDE processes that may update table - this can lead to referential integrity issues.

From a pure philosophical view point, I generally dislike any kind of table trigger (JDE or DB), however, they have their place and use and sometimes they are the best solution to a problem. In general, I prefer to keep business logic out of the database. Even our DB triggers have caused me grief. There have been times were I debugged an issue for days because debugging the code showed one thing was supposed to happen but the database showed something else happened. Table triggers tend to lead to obfuscated solutions.
 

BOster

Legendary Poster
How does one "Java Gen on the table object"
Look for LaunchGen.bat under the [jde install path]\system directory, most likely in the OC4J folder. This will launch the old javagen app that we used to have to use back in the old Xe days. I have had to use it from time to time, generally when I make a change to a DD item or when I change a client only NER (if that NER has been previously called by the APPL).
 

craig_welton

Legendary Poster
To help troubleshoot ... can you confirm the trigger fires if the table is changed by a UBE or BSFN? I am assuming the table update/insert is being done within an app which is a very different runtime.

Craig
 

nkuebelbeck

VIP Member
To help troubleshoot ... can you confirm the trigger fires if the table is changed by a UBE or BSFN? I am assuming the table update/insert is being done within an app which is a very different runtime.

Craig
I'm assuming it's fired from B3201600. something i did(restart,rebuild table trigger, clearing global tables, smashing my face against the desk,kicking my dog) must have worked because the trigger works now. So thanks everyone for your help.
 

craig_welton

Legendary Poster
One thing to be aware of (among many of the trigger pitfalls Brian explained), is that the trigger will not fire if more than one record is affected with your action. For example, update with a partial key and no trigger is fired. Pretty weak.
 

nkuebelbeck

VIP Member
is there a way to check if the table IO was successful? or can it be assumed that if the event fired it was successful?

In the After Record Inserted for instance, would it ever have NOT inserted? same would for delete/update
 

nkuebelbeck

VIP Member
One thing to be aware of (among many of the trigger pitfalls Brian explained), is that the trigger will not fire if more than one record is affected with your action. For example, update with a partial key and no trigger is fired. Pretty weak.
Just ran into this one with a delete not firing delete trigger.
 

jdelisths

Reputable Poster
To my knowledge, the trigger will not get executed if the corresponding insert/update/delete fails. Regardless, you should see errors in the JAS log (if invoked by an app), jde log of the UBE or the jde log of the call object kernel.
 

nkuebelbeck

VIP Member
To my knowledge, the trigger will not get executed if the corresponding insert/update/delete fails. Regardless, you should see errors in the JAS log (if invoked by an app), jde log of the UBE or the jde log of the call object kernel.
in this case, i attached a trigger to the insert and the insert fired twice. I assumed it would have failed one of the times, but to my now excellent trigger knowledge, it was probably deleted with a partial key between inserts
 

alfredorz

Well Known Member
If you don't use BSFN's in trigger, I thing it's better create trigger in db directly because you can debbug better, don't need deploy, etc. less problems XD

Are you try deploying the table?
 

nkuebelbeck

VIP Member
If you don't use BSFN's in trigger, I thing it's better create trigger in db directly because you can debbug better, don't need deploy, etc. less problems XD

Are you try deploying the table?
I ended up attaching out own logic to a stock object. triggers are meh at best.
 
Top