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… 😉
Stefano Demiliani 
Hi how can we will do in PK case?
i added 3 filed in 1st version now in next version i am removing one filed out of it.
keys
{
key(PK; Exam_No,ID ,Line_no)
{
Clustered = true;
}
}
i had removed ID filed from my PK.
should i write obsolete in PK like below
key(PK; Exam_No,ID ,Line_no)
{
Clustered = true;
ObsoleteState = Removed;
ObsoleteReason =’Not in use’;
}
Please guide me how we can apply obsolete in PK case .
Thanks.
LikeLike
If you need to change a primary key of a table from a previously deployed 1.0 extension, you need to create a new table and mark the old table as obsolete. In your Upgrade codeunit, move the data from the old table to the new table.
LikeLike
Hi Stefano,
I was trying to find out for how long 0″Marked for removal” fields and tables are kept in the database. I was wondering in particular for the Sales Price and purchase price tables.
Do you have any updates or knowledge about when these tables will be removed? Could it be in the next bc17?
LikeLike
Plans are for v18.
LikeLike
Do you know about any news regarding this topic?
LikeLike
No physical fields removal on SaaS at the moment.
LikeLike