kriki: OnDatabase-triggers in codeunit 1

[Blog bot]

First a small introduction for those who don’t know the OnDatabase-triggers yet.

In the beginning (don’t worry, this not a fairy tale, but it is some history), there were only the "OnGlobal"-triggers in codeunit 1.

But these had a small problem. They were only called when a user changed data. It did not intercept changes done by C/AL code statements.

So if you wanted to monitor ALL data from a table, you had to find all INSERT/MODIFY/DELETE/RENAME/MODIFYALL/DELETEALL-statements on all the records (and recordreferences!!!) of that table. Not so easy.

With NAV2009R2, NAV was closely integrated with Microsoft Dynamics CRM and all changes in some tables had to be replicated to CRM. It was not an option to search all the code and manually add some code that also called the OnGlobal-functions (or the functions in them).

So Microsoft gave us the OnDatabase-functions in codeunit 1 and those intercepted ALL changes to the data, included the C/AL commands that change data.

They work so well that even if you do a RENAME on some table. Lets say you rename a "Payment Terms Code", NAV searches the old payment terms code value and changes it to the new one in the whole database (of course, you need to have tablerelation on the fields) and if the table in which it changed must be monitored, NAV fires the onDatabaseModify-function on that table.

So this seems to work perfectly.

No, not really, there is a problem with it, I found out.

Lets take again the "Payment Terms"-table.

Lets say you have a master-company in which you do the setup. That setup is than copied to all other companies in the database.

So in the OnModify-trigger of the table, you probably have some code like this (this is NOT a good example of PRS-methodology! ).

Company.RESET;

Company.SETFILTER(Name,’<>%1′,COMPANYNAME);

IF Company.findset THEN

REPEAT

CLEAR(PaymentTerms);

PaymentTerms := rec;

PaymentTerms.CHANGECOMPANY(Company.Name);

PaymentTerms.MODIFY(FALSE);

UNTIL Company.NEXT = 0;

What happens in the OnDatabaseModify-trigger?

Well, for each MODIFY, the trigger is fired like expected (….eh… let me rephrase this…).

The trigger is fired for each MODIFY, but it is always fired IN CURRENT COMPANY! And not in the other companies! And there is NO WAY to know in which company the trigger was fired.

And this is not so good. Because we might need to trace it in another company.

And maybe, the same table is NOT even configured to have the OnModifyDatabase-trigger fire in another company.

So be careful!



Читать дальше