Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.5K Microsoft Dynamics NAV
- 18.5K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 262 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 992 SQL General
- 385 SQL Performance
- 33 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 259 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Options
Extension V2 - Upgrade with Destructive Schema Changes with Upgrade Codeunit
StLi
Member Posts: 83
Hey,
I'm doing a little bit of prototyping at the moment but there will definitely come the time when i need this.
In the MS Docs there is this article, that implies it is possible to do destructive Schema changes and handle those with an upgrade codeunit.
However, even with the most simple example I can imagine, I couldn't figure out how this upgrade is supposed to happen.
Does anyone of you know of a working example for that? Because the Docs are suspiciously example-less in that regard.
What I did was:
As you probably noticed, I'm consciously trying to provoke an error as soon as the Upgrade code is executed. - Just to find a "point of entry" to handle anything regarding the existing Data during an Upgrade.
I already tried using VSCode to do my Upgrade for me with another example. But it either deletes all my data when i use schemaUpdateMode = Recreate. Or fails publishing at all with schemaUpdateMode = "Synchronize".
So at this point i tried to do the deployment manually. I am able to publish the upgraded Version. But when I try to Sync, i get a complaint about my destructive schema change and when i try to skip directly to the upgrade, the NST complaints that the schema must be synced first.
It seems to me like I hit a wall at this point and there is no real embedded solution to solve this. Or I'm missing something big here.
Thanks if you have any helpful information on this.
p.s. I also raised an issue on Github about this.
I'm doing a little bit of prototyping at the moment but there will definitely come the time when i need this.
In the MS Docs there is this article, that implies it is possible to do destructive Schema changes and handle those with an upgrade codeunit.
[...]then the table data cannot be synchronized and you have to either use the Recreate mode or write an upgrade codeunit.
However, even with the most simple example I can imagine, I couldn't figure out how this upgrade is supposed to happen.
Does anyone of you know of a working example for that? Because the Docs are suspiciously example-less in that regard.
What I did was:
- create a new extension
- Set the Extension Name to "DestuctiveUpgradeTest"
- add a new table with two fields {"Entry No.": Code[10], "UselessField": integer, "UsefullField": integer}
- add a new list page to show the table.
- Build,publish,install,run Page via Debug mode
- Put 5 records into the table using fields "Entry No." and "UselessField" (leaving "UsefullField" on default)
- Raise Version of Extension to 1.1.0.0
- Add Parameter "Enabled = false" to "UselessField"
- Create Upgrade Codeunit with Trigger "OnUpgradePerCompany()". Raise manual Error('Test');
- Create a new Package
As you probably noticed, I'm consciously trying to provoke an error as soon as the Upgrade code is executed. - Just to find a "point of entry" to handle anything regarding the existing Data during an Upgrade.
I already tried using VSCode to do my Upgrade for me with another example. But it either deletes all my data when i use schemaUpdateMode = Recreate. Or fails publishing at all with schemaUpdateMode = "Synchronize".
So at this point i tried to do the deployment manually. I am able to publish the upgraded Version. But when I try to Sync, i get a complaint about my destructive schema change and when i try to skip directly to the upgrade, the NST complaints that the schema must be synced first.
It seems to me like I hit a wall at this point and there is no real embedded solution to solve this. Or I'm missing something big here.
Thanks if you have any helpful information on this.
p.s. I also raised an issue on Github about this.
0
Answers
Create a new field and mark the old one as obsolete, and let upgrade cu move the data.
yeah, i kept investigating and it looks like this is the inteded behaviour as microsoft wants you to maintain full backwards compatibility on anything ever released... I kinda was unaware of the "Obsolete"-Properties as I was looking for anything related to the word "depreciated" for some reason. - Otherwise I probably wouldn't have put so much time into this.
Just to save some time for anyone else:
There are some workaround options for On-Premise solutions:
1. Use SQL:
- rename affecte extension-Table
- rename affected keys (index)
- delete the right records in [$ndo$navappschemasnapshot]-Table
- install updated extension (with the undesired fields removed)
- insert records from renamed table to newly recreated Table
- delete renamed table and keys
2. Use Upgrade Extension:
- Create a dependant extension with a copy of the Table you want to change.
- make upgrade extension dependant on original
- OnInstallPerCompany(): copy Data from old original to upgrade extension
- raise upgrads exensions version no and remove dependancy to original extension - remove install CU as it will lack all the referenced fields
- Upgrade the upgrade extension on Server
- Unpublish and Sync-clear the original extension
- raise original extensions version. Change whatever actually needs to be changed
- install new original extension on Server
- raise upgrade extensions version and make it dependent on the new Extension again
- OnUpgradePerCompany(): move all the Data back onto the originals' Table.
- Unpublish and Sync-clear the upgrade extension
And then there is one version that is not dependent on sql access or the authorization to use the Sync-clear command:
Basicly, simular to the Upgrade Extension but you copy the whole extension and just renumber and rename all objects, and then stay at the new Extension and Unpublish the old one.
It's not hard to find any undesirable aspect in any of those solutions but now i shared the results of my research. - I'll stick with "obsolete"-Properties and "don't create unnecessary fields in the first place" as far as I can.