Table Trigger on F0101

bwilkinson

bwilkinson

Well Known Member
I put Microsoft sql server table triggers on the F0101 for Inserted,Updated and Delete and they are working fine my question is on the Updates it looks like JDE updates the table a lot as in in 1 24 hour period I have over 4500 updates to the table.

In most cases it looks like just the abuser,abpid,abupmj are getting updated mostly from UBE's getting run. Is this normal?
 
Bill,

It has been a while, since I played with a similar issue to what you are seeing.... Updates to the F0101 happen thousands of times a day....

Many (very many) applications/functions hit the 'Address Book Server' process. Basically - when the AB Functions pull / return the address, they look to see if the address is 'current' and 'valid', then update the table 'regardless' of a change. The code works GREAT, but it is, IMO - a sloppy means to validate and make-right.

There isn't a really 'good' way around it.

(db)
 
[ QUOTE ]
I put Microsoft sql server table triggers on the F0101 for Inserted,Updated and Delete and they are working fine my question is on the Updates it looks like JDE updates the table a lot as in in 1 24 hour period I have over 4500 updates to the table.

In most cases it looks like just the abuser,abpid,abupmj are getting updated mostly from UBE's getting run. Is this normal?

[/ QUOTE ]

Triggers on a high transaction system like EnterpriseOne are very, very nasty. I generally only employ them on CNC/System tables like F00950, F986110.

If your organization is looking for SQL auditing, try a commercial package specifically for that. They are a couple out there that do not rely on triggers.
 
[ QUOTE ]
Triggers on a high transaction system like EnterpriseOne are very, very nasty....

[/ QUOTE ]

Definitely. I dealt with a customer who implemented a Cast Iron appliance for integration purposes with a "tiny" virtualized implementation of E1. They were using triggers on the F0101, among other tables, with SQL Server 2005.

The result, as soon as the triggers were added? Address Book entry failed from the Fat and HTML clients.

Our "solution" was to add SET NOCOUNT ON to the triggers. My ideal "solution" would have been something far more drastic.
 
It depends on your situation, size, transaction volume.

We use DB triggers to log changes to a number of tables with no incidents. A simple JDE Inquiry application accessible via row exit from the standard maintenance applications makes change auditing easy and removes a considerable load from IT responding to users wanting to know "who changed this?" (frequently they themselves did but thats another story).

To avoid issues such as the OP posted (entries with no changes) we filter out most UBEs that are not user initiated as we are mainly interested in identifying who changed what when.

Our biggest log table is < 10M rows. Disk is cheap but whatever your comfort level you can setup a regular SQL job to purge old history.
 
Back
Top