Rock’n’Roll! That is my first – official – super verbose and actionable error message during Sync-NAVTenant on the road to version #23.
I know. This is the good old grumpy PowerShell: not so verbose. And it forced me to wake up the even older SQL Server Profiler trace.
Ah Gotcha.
This is yet again the consequences of the new table structure. In this database on-premises, there are custom created SQL Views that are referencing companion tables. Such views must be removed manually before the upgrade, refactored, and deployed again in version 23, post upgrade.
This is the price to upgrade (on-premises).
Fixed the problem, Synchronization ran smoothly in 9 minutes (read: in 9 minutes from the old to the new table extension data model).
At the end of the upgrade:
- From a total number of rows in the database (122.183.786) the synchronization reduced them to 78.637.352. That is approx. -35% of the number of rows in the database (more than 1/3 of the rows were gone, better say transformed).
- From 8.859 Tables to 7.929 Tables (-930 Tables)
- Database dimension drop from 82.3K MB to 79.9K MB (-2.4 GB approx.)
Other goodies from this upgrade include:
- Rename instead of drop.
During the upgrade, if there is only one single companion table, instead of the CREATE, INSERT INTO, DROP sequence, the procedure wisely renames (sp_rename) the table object instead. And of course, a yellow card is raised into the profiler trace every time it happens: “Caution: Changing any part of an object name could break scripts and stored procedures.”.
This is the clear sign that the synchronization process is renaming the only companion table instead of performing all the create new, insert into, and drop mambo-jumbo.
- Remember to create statistics.
SQL Server, like a good friend, will always remember you to create statistics, when needed.
An upgrade of this size means a new bunch of tables with a discrete number of records will be created. Remember, then, to create statistics right after the synchronization and take the chance to review your maintenance plan to be sure these will be up to date before start working with the new shiny version 23.
What about SaaS deployment vs column statistics? Well, that is a good question. I do not know right now if statistics will be automatically created during (I believe so) or right after synchronization or somewhere in time, but I am confident Microsoft has in place the best strategy to avoid performance bottlenecks right after upgrades.
Dynamics 365 Business Central tales, myths, legends. And something serious. 
Hi Duilio I’ve similar problem. During an upgrade FROM BC14 to BC25.
The process stops with this error:
An unexpected error occurred after a database command was cancelled.
From the events log, it’s clear that the problem is a SQL command (exec sp_rename) that fails because the object to be renamed doesn’t exist. The strange thing is that the object it references cannot exist because it contains the GUID of the migration extension but it’s an ext object. For example:
NOMECOMPANYSales Invoice Header$93456c23-dc9a-4bd3-aa53-83d7bde201df
ext”
What actually exists is the same object but with the Base App GUID obviously:
NOMECOMPANYSales Invoice Header$437dbf0e-84ff-417a-965d-ed2bb9650972
The strange thing is that I tried running the migration process again by recreating the migration extension. What changed is that before, this exact same error was on the Purchase Header, now it’s on the Sales Header.
Do you have any suggestions on how to solve this problem?
LikeLike
Hard to say. It seems to me that you might have missed some upgrade steps in-between and/or you have some synchronization problem in the source database. What I suggest is in v14 to be sure to have synchronized the app successfully and the database is fully operational. After that, I would try to move the database with an intermediate step like v14 to v22 and then v22 to v25. Why? If it succeed, good. If it does not and going to v22 work just fine then it corroborate the hip that you are missing some upgrade steps.
LikeLike