[question/issue] Rec.CHANGECOMPANY with event subscribers

[hhfiddelke]

Scenario:
A given record with event- subscriber is inserted/modified/deleted with a CHANGECOMPANY before.
How can we preserve an (unknown) event- subscriber to be fired that it modifies data in the current company where the record- data probably does not exist?

Currently in C/AL we call INSERT/MODIFY/DELETE with FALSE, and the associated trigger is not fired.

[dagirard]

Since triggers not on the record are not run in the changed company, then the recommended pattern is to avoid writing to a different company.

This can be obtained by creating a new background session in the 'destination company' which does the writing and then it only reads from the original company.

However, be aware that the two sessions do not run in the same transaction, and hence transaction integrity cannot be assured across the two sessions.

[hhfiddelke]

That these triggers are not run in the different company may not be an good idea.
Inserting a new item in the other company may require triggers who insert dependent data in the other company.
Doing this in a sepearate session might be also a problem, if other code afterwards want's to change the inserted data in the changed company.

I would recomend to fire the triggers in the destination record's company by default (i personaly do not know a case where it should be different, but may be).
If a property is set at the - VERY IMPORTANT - eventsubscriper, it is fired in the calling company.

[dagirard]

This is how Business Central (NAV) worked since the beginning, and it's documented here:
https://docs.microsoft.com/en-us/dynamics-nav/changecompany-function--recordref-

Even if you run the CHANGECOMPANY function, triggers still run in the current company, not in the company that you specified in the CHANGECOMPANY function.

This is why we recommend to create a new background session in the destination company, that will triggers all the proper "events/triggers" in the right company, and not the current one.

[hhfiddelke]

May that this is documented. but i know no subscriber which checks this.
The code which does the CHANGECOMPANY is unable to check if there is a subscriber, and also not which tables this subscriber uses. So CHANGECOMPANY is extremly unsave.
So to be save: CHANGECOMPANY should be set to ObsoleteState=Removed.

And once again: A performant System is eventdriven. Sessions that eventualy run in background are nothing you should rely on, because it's out of sync, and if there is an error, the data may be compromised.

[dagirard]

Thanks for the input, but changing now the behavior of CHANGECOMPANY would be breaking. If we decide to change the way events and/or CHANGECOMPANY works this will be definitively considered.

About the background session and error handling/data compromised, you can consider relying instead on the task scheduler (https://docs.microsoft.com/en-us/dynamics-nav/task-scheduler)

[hhfiddelke]

Sorry i know how bad the job queue in NAV works, i think there is no realy difference in BC or NAV2018.
After every Windows- update and reboot the chance is 50% that the taskscheduler is running correctly afterwards.

[hhfiddelke]

Have a look on the CHANGECOMPANY- calls in the standard- code, and understand what may happen, if an potential eventsubscriber is called in the wrong company.

[StanislawStempin]

The owning team has been made aware of the problem but there are currently no plans to address it. I will close the issue here since it's not directly related to developer tools and AL language.