#msdyn365bc - A New Variant of OnInsert.

Hi Readers,

In this article we will understand How our well Know On Insert Method is Changed.

As the Product is changing there are changes in legacy Method. We should be aware about them and also utilize them if we have a scenario where its needed.

A Product which is connected to outside world in a completely different way than in Past have to change/update the core.

With Business Central 2020 Wave 2, Microsoft Introduced 05 new fields in all tables in Business Central.

•  $systemId
• $systemCreatedAt
• $systemCreatedBy
• $systemModifiedAt
• $systemModifiedBy

There was a very clear message with these fields addition. These fields were used when third party applications & other Dynamics 365 applications interacts with #Msdyn365bc to read / write Data using API.

API does not rely on Primary key of table. API's rely on $systemid to read record and third party & Other Dynamics 365 application use other system fields to understand that record is changed or not.

How Does all that Impact?

• System Audit Fields are set and Updated during Insert, Modify, Delete & Rename operation in Tables.

• $SystemId gets assigned to a record when Record is Inserted and Does not change after that.

• SQL also creates an Index based on $SystemID Field.

Scenario - Where $SystemID will change?

• In your extension there is a Table that you added in Version 1, Customer have records in table.\

• In Future You plan to renumber the table or Move that data to a different table in your extension and Mark the Existing Table as Obsolete.

• ** Don't delete data from old table yet. It might be needed by other third party application till they switch to New Table.

• Your Upgrade Codeunit will be something like as shown below.

• In Both Situation - Insert() or Insert(True) System will assign a New ID to each record in New Table.

So What's the Issue?

• The External Integration will treat all records in New Table as New Records which is not correct. (Records moved from one table to another).

• We need a way to keep the ID intact.

How Microsoft Achieved That?

Microsoft have added an New Variant of OnInsert Method. 

Now OnInsert have three Version - 

•  OnInsert 
• OnInsert(RunTrigger)
• OnInsert(RunTrigger,InsertWithSystemID).

Default Value - 

• RunTrigger - False.
• InsertWithSystemId - False.

What Happens If we change these Parameters to True - 

 RunTrigger - True  If this parameter is true, the code in the OnInsert Trigger is executed.

 InsertWithSystemId - True  If this parameter is true, the SystemId field of the record is given a value that you explicitly assign. If a value is not assigned, then the platform assigns one. 

MSDN Documentation 

How Should we write our Upgrade Routine?

• We Should Transfer the SystemId from OldTable to New Table after the Transferfields.

Don't use this feature as a Loophole?

• As in Microsoft Doc, Don't assign SystemId Manually. GUID's are unique and should remain that way. 

• Never Assign GUID Manually. There is a chance to have that ID used somewhere else. 

• Use CreateGUID A/L Method to get a New GUID if required.

Hope you understand the New Variant of Insert Function and Usage Scenario for Same.

Let me know your views as comment to article.

Regards,
Saurav Dhyani
www.sauravdhyani.com