I have been writing Table Event Rules (AKA Table Triggers) for many years now and have found them to be a stable and useful tool, especially in the more recent versions of OneWorld/EnterpriseOne.
I would, however, recommend that you find alternate methods of coding. TERs sorta hide behind the scenes and can cause troubles since they’re often forgotten. The actual functionality can be forgotten and cause troubles when another task simply wants to write a record or read something and the information doesn’t match what is expected or a batch job is somehow submitted. The debugging time can outweigh the benefits. And no one really wants to be cussed in their absence.
However, as my own devil’s advocate, if the task needed in the TER is simple and straight forward, putting it in a TER can simplify the task, especially if the need dictates changing the code in many different programs.
What I have found to be a successful implementation in many instances is a combination of Named Event Rules (NER - more control and functionality than a TER allows) and the application/UBE level. Before or after the IO call, call an NER that does the work. The benefits are that the code is not hidden, but is encapsulated in a more object oriented manner and can be called or ignored based on the need at the time. It does require a certain amount of discipline by your programming staff, but I hope you already have that.
As to using SQL server to add triggers to the table, see argument #1 above – It can be a benefit, but can cause more troubles than it’s worth if its done wrong. Keep it all in EnterpriseOne. If you use NERs as mentioned above, you will have control over your application and the details will not be hidden from your developers.
