Al: RunTrigger in TableExtension triggers

Created on 22 Feb 2018  路  7Comments  路  Source: microsoft/AL

I might have overlooked something, but currently all our OnTableTrigger / OnValidateTigger subscribers are managed in separate codeunits. With the move to extensions v2, this code will be refactored / moved towards a Table Extension object . However, I can't find the parameter 'RunTrigger' in the triggers OnBeforeInsert, OnAfterInsert, ... How can I avoid code being ran if the RunTrigger had not been set?

question

Most helpful comment

We have an ongoing internal discussion about this subject. One of the problems is that the base application uses RunTrigger=false in way too many places, only because the default was False. So we might want to fix the base app instead of adding more features that support the wrong behavior.

All 7 comments

These triggers will only run if the base trigger was run so you should see the behavior that you want without having to rely on the RunTrigger parameter.

And what if I wanted to have my code always executed, even if the base trigger is not run? Should I then switch back to a custom subscriber instead?

Yes, in that case you still need to use an event subscriber

Could it be a future improvement to get the RunTrigger parameter in the Table Extension triggers as well? This would avoid the use of subscribers and allow handling both cases via table extension object triggers instead.

We have an ongoing internal discussion about this subject. One of the problems is that the base application uses RunTrigger=false in way too many places, only because the default was False. So we might want to fix the base app instead of adding more features that support the wrong behavior.

Before extensions v2, we could already use the OnBeforeInsert event subscriber and put all logic in that subscriber. The advantage of that approach was that the subscriber was always called and would allow conditional logic based on the RunTrigger parameter. This allowed us to catch in on lots of standard code (especially where the INSERT trigger was not explicitly called), without having to modify the base app and change it to INSERT(TRUE).

The same seems to be still possible with extensions v2, but in addition, we have the OnBeforeInsert trigger for table extension objects as well. The first approach gives us the option to catch in to both scenarios (INSERT and INSERT(TRUE)), the last approach is cleaner / more intuitive for code writing, but seems to catch only the INSERT(TRUE) case.

If we could have the OnBeforeInsert trigger for table extension objects being called always (both for INSERT and INSERT(TRUE)), in addition with the RunTrigger, that would be ideal (without the need to modify the base app).

In case the base app would be updated, there would still be some places where INSERT is called without calling the table trigger, but we would still like to subscribe to it in our extensions ... so still requiring to call the event subscriber instead of using the table extension trigger.

Curiuous for the final result :)

To close this thread - we are currently not planning to change the base application so the behavior of triggers and events will remain the following:

  • Triggers in extensions will only run if the trigger in the base object ran
  • Event subscribers will always run and provide RunTrigger parameter to be used by subcribers
Was this page helpful?
0 / 5 - 0 ratings