The views and opinions expressed in this blog are those solely of the author(s) and do not necessarily reflect Microsoft’s current policy, position, or branding. For official announcements and guidance on Dynamics 365 apps and services, please visit the Microsoft Dynamics 365 Blog.
Personalized Community is here!
Quickly customize your community to find the content you seek.
Check out the latest Business Central updates!Learn about the key capabilities and features of Dynamics 365 Business Central and experience some of the new features.
Download overview guide | Watch Business Central video
2020 Release Wave 2Discover the latest updates and new features to Dynamics 365 planned through March 2021.
Release overview guides and videos Release Plan | Preview 2020 Release Wave 2 TimelineWatch the 2020 Release Wave 1 virtual launch event
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
I saw many requests on forums in the last days related to one of the most noisy topic when working with Extensions in Dynamics 365 Business Central (SaaS version): how to handle breaking schema changes.
The tipical scenario is the following:
ERROR: “Unsupported table change” message or (for keys) the message is something like “An unsupported key change was detected. Keys cannot be changed, removed, or reordered. New keys can only be added to the end of the list“.
Previously (in the C/AL era) if you change a field property on a table or if you change a table’s key and you’re sure that this will not occour in a data loss, you could export the fob and import them in the production environment using the force option and all works.
Now in the cloud environment things are different.
Extensions V2 do not support breaking schema changes across synchronized versions of the extension. Uninstalling and unpublishing the 1.0 extension will not remove the schema elements coming from an extension.
In your local sandbox environment you can “clean” your environment in the following ways:
Sync-NavApp -Name <name of extension> -Version <Version of extension> -Tenant <Tenant name> -Mode Clean
This will remove all the schema elements across all versions of the extension (and also all the data). The next time you will deploy your extension, the system will not found an “old schema” to compare agains the new schema and all your changes will be considered as new.
What about in the production environment?
In a production environment, once an extension is synchronized to a tenant then all the next versions (upgrades) must have a compatible schema that is backward compatible. To handle this scenario (that can occour, I agree…) you can:
The ObsoleteState can have these values:
If you need to change a primary key of a table from a previously deployed 1.0 extension, I think the best way is 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.
Lesson learned after this post? That in the SaaS era, you have to deploy in a production environment more and more carefully than before and only when your design is really ready!
Business Applications communities