Dynamics 365 Business Central 2022 Wave 2: the evil of the new field changes behaviour

In the year 2001 after my Master Degree in Computer Engineering I joined a new team inside my company of that time (located in Turin) that had assigned a very exciting project: moving a big distributed application for the cinema industry written in Visual Basic 6 and with SQL Server as backend to a new distributed architecture based on .NET 1.0 and web services.

I remember that we started this very big project (big names of the cinema industry were impacted by this new redesign) asking directly to Microsoft for some consultations on how to handle the software architecture design at best (how to design at best the application layer, data layer, database access, web service layer and so on). An year later I had the pleasure to manage this team and about 1.5 years later the project had the go-live phase. But that’s another story.

From that time, I remember the lots of lessons learned from Redmond’s people on how to design a scalable and layered windows application with .NET and regarding the data layer (my focus on that project was to design and develop the backend, so the data layer and the web service layer) I remember some principles:

• Acquire late and release early: keep your thread of execution’s use of the shared resource as brief as possible. Acquire the connection you need for your data as late as you can in your code, and as soon as you’re done with it, release it.
• Avoid too much roundtrips to the backend.

Why I’m writing these things in a Business Central-related post?

Yesterday my eyes was caught by the following slide:

I’ve to admit that I had totally missed this aspect, despite the testing during the preview steps of version 21. Field changes now saved to database when leaving field? My first reaction was: but this behaviour is different that version 20 (and before) and this can affect not only applications (extensions), but also users!

Why I’m saying this?

To explain the changes, I’ve uploaded on two different envirionments (version 20.5 and version 21) a simple extension that adds an action to the Customer Card page for printing the Gen. Bus. Posting Group field value:

The Adatum Corporation customer has the Gen. Bus. Posting Group with the value setted as NAZIONALE in the IT localization:

Now imagine the following scenario: a user of the administrative department of CRONUS (here called user A) opens the Customer Card for customer 10000, changes the Gen. Bus. Posting Group field to a new value (like UE) and starts a long phone call with a colleague, asking if the UE value is correct or not.

If during this time another session (user B) reads the Gen. Bus. Posting Group field of customer 10000, this is the behaviour in version 20.x:

The field is changed to UE in the user A session but user B when reading the Customer 10000 record reads the value committed to the database (NAZIONALE).

Data is committed to the database when the user closes the page.

Now let’s do the same scenario in a version 21 environment, where the new behaviour of saving work is in place. What happens now? This:

User A changes the field to UE and user B immediately see the changes when reading the same record in its session, also if user A has not closed the Customer Card page.

You can also verify the new behaviour by creating a tableextension object of the Customer table and adding a message in the OnAfterModify trigger of the table. You will see that for version 20 this is triggered when the page is closed, on version 21 this is triggered on every field modification.

Good or bad behaviour?

I honestly don’t like this behaviour. I think that this generates a lot of roundtrips to the database and they can affect performances. But despite this, there are two more important side effects:

• This can have an impact on your extension code/behaviour when a record is modified.
• This have an impact on how your users work: you have to instruct the users that now every modification they do is immediately physically saved to the database. And if they do wrong things (like start changing the Gen. Bus. Posting Group of a Customer to a wrong value and then starting a phone call with a colleague thinking that this change is temporary and not visible to others) they’re wrong and they can break business processes.

If you have a change tracking system that monitors for records modifications, please take this into consideration too.

And what about if you subscribe to the OnAfterModify trigger of a table to do actions in your extensions? This can have an impact too.

This behaviour can be changed in the on-premise version by setting the SaveValueToDatabasePromptly opton to FALSE in the navsettings.json file in the Business Central web server folder (C:\inetpub\wwwroot\YOURBCFOLDER), but for SaaS you cannot disable it.

The SaveValueToDatabasePromptly flag instructs the web server to send each field to the service tier and have it saved in the database, raising also all the associated events.

I honestly hope that the possibility to disable this behaviour also for SaaS will be available in the future, because this is not an optimal behaviour and this is not a behaviour that many customers want. In the meanwhile, open an alert on this.

UPDATE: Microsoft reacted to this post with this decision:

Dynamics 365 Business Central 2022 Wave 2: the evil of the new field changes behaviour – THE HAPPY ENDING