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.
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
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.
Regarding deleting of objects, is there a way to automatically create “killer objects” that could be used to remove objects, as seen here: http://www.archerpoint.com/blog/Posts/killer-objects
Thanks for the link – wasn’t aware of this.
Do know that we are working with delta’s .. and I have a feeling (didn’t test) these so called “killer objects” only work as fob.
But there is another solution which I’m going to blog about. In short: analyze the “updateresult” you get back from the “Update-NAVApplicationObject”. Deletions are marked as UpdateResult=Deleted. You can loop these and use the “Delete-NAVApplicationObject” to delete it in the database. I use this in my function “Apply-NAVDelta” on my github here: https://github.com/waldo1001/Cloud.Ready.Software.PowerShell/blob/master/PSModules/Cloud.Ready.Software.NAV/ModelTools/Apply-NAVDelta.ps1 .
Hope that helps 🙂
Indeed these killer objects are working only when fob is imported.
Thought so – and delta’s are creating text files .. . So these just don’t cut it, I guess.. .
I will check your solution on GitHub 🙂
dude .. come on .. you just totally wasted my time ..
😛 Thanks, this is really a good trick!
Its indeed a very simple but powerful approach.
As a partner I very often find that the license restrictions prevent me from using deltas altogether simply because our development license does not allow importing a 3rd addon as .txt-files.
Furthermore, some objects may be locked for customization meaning I can’t export them as .txt later on, if I initially import them by .fob.
I don’t understand why I don’t see that as an issue raised on the various NAV blogs.
Is that not something you run into Waldo, or do you develop all your addons yourself (meaning you have license to create objects in the the object range)?