Dynamics 365 Business Central: again about obsoleting fields

More than an year ago I’ve written this post explaining how to handle breaking schema changes on a production Dynamics 365 Business Central SaaS tenant. I think that every Dynamics 365 Business Central developer now knows that in a production environment you cannot remove objects or fields (breaking schema in the database) but all schema changes must always be additive.

Despite this, I see lots of developers that does what I try to describe in this quick post. As first step, they create a version 1.0.0.0. of an extension that defines a new table object with some fields:

Then, on version 1.0.0.1 they decide to remove for example an existing field and they declare it as ObsoleteState = Removed:

Then, after some time they create a version 1.0.0.2 of the extension where they want to add new features and a new field in the table. A quite common error that they do is as follows:

What happened here? Lots of partners thinks that when a field is declared as ObsoleteState = Removed and deployed on a production tenant, this is physically removed by Microsoft in a next tenant upgrade. So, as you can see in the above code, they added a new field (here called ISBN) and they remove the obsolete field from the AL code definition.

What happens when you deploy this extension to a Dynamics 365 Business Central tenant? ERROR: unsupported breaking schema changes!

Please always remember that when you declare a field (or an object) as ObsoleteState = Removed, this is not physically removed from the database schema. Microsoft actually has not enforced a policy for physically removing obsolete fields from the database, this is at the moment only like a “mark” that prevent you (and your partners) to use the field (or the object). Obsolete fields are actually never physically removed also during a next major release upgrade. The right way of work when you need to declare fields as obsolete is to always maintain those field definition on your AL code, like in the following code:

In this way, you don’t have breaking schema changes and your extension will be correctly deployed.

A common question that I always receive is: when my ObsoleteState = Removed fields will be really deleted from the database schema? Microsoft is working on activating this “cleanup” of obsolete fields, announced plans are for the v16 release (April 2020) but there are no official announcements yet, so please remember this blog post

Happy New Year now…