I’m going to explain you a concept that is so simple that you’re probably going to react like: “dude .. come on .. you just totally wasted my time .. this is so obvious.. can’t believe you just don’t take this for granted”.
But I’m still gonna. Just because of the fact that the concept is so simple, that at first, I just didn’t think of it to use it like this.
Deltas
You know all about Deltas, right? It’s the type of file you can create with PowerShell (Compare-NAVApplicationObject) that describes the changes you did on specific objects. You can apply this file to an object file, also with PowerShell (Update-NAVApplicationObject), which basically merges all these described changes to the object file. Good stuff .. especially in upgrade scenarios.
It’s a way to transport changes and easily merge changes in a database by:
- Exporting the objects to text from that database
- Apply with PowerShell
- Solve conflicts if any
- Import the objects
- Compile
What if I want to remove the changes back from the database?
Well .. Deltas describe changes. So it also describes the removal of any kind of control, property, object, .. . Also THAT is a Delta. As such, if you apply a removal of a field to a table .. your result will obviously be a text file of the table object, without that field. Furthermore, if your delta describes the removal of an object .. the result folder will not contain that object, and the “updateresult” will contain the list of objects that were removed. You can work with that!
But how do I create such a delta?
Well, also this is obvious: you create a delta by comparing two versions, right? The ORIGINAL and the MODIFIED. And you end up with a description of what you did in the modified database. Well, you can easily create a so called “reverse delta” (probably there is a better word for it) by switching the two: as original, you take the modified, and as the modified, you provide the original. You will end up with the exact opposite delta. And in my opinion, you should always create the two deltas: the modification, and the one to reverse the modification are equally important.
I used this in the field
A while back, we were implementing an add-on, and realized that the add-on just didn’t cut it for us. So basically, after quite some time, we had to remove the add-on (+300 changed objects) out of our database. This turned out to be very simple: I used that “reversed delta”, and removed it without any pain, including text constants, fields, local variables, undocumented code, .. and all other pain anyone faces when doing this kind of removal jobs manually.
So how do you handle the deletion of Objects
As you know, when you import a text file, NAV is never going to remove objects. This needs to be handled by either you manually, or your script. You can do it easily by looping the Updateresult-object you get back from the Update-NAVApplicationObject cmdlet, in combination with the cmdlet to remove objects: Delete-NAVApplicationObject (which doesn’t seem to be on MSDN). I added this to functions – which I will talk about in one of the next blogposts where I will explain some functions I added to my repository on GitHub to work with Deltas more easily.