E1 Table Trigger

nkuebelbeck

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
 
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
 
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.
 
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
 
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."
 
Try closing out of E1 and deleting the glbltbl.* tables in your path code folder (c:\E910\dv910 for example)
 
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.
 
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).
 
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
 
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.
 
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.
 
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
 
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.
 
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.
 
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
 
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?
 
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.
 
Back
Top