Skip to content

Dynamics NAV Killer Objects

I didn't invent Killer Objects nor the term. But, I've used them occaisionally over the years and will now describe what they are and how other developers can find them useful.

Everyone knows that the Import Worksheet is primarily used for importing new objects and replacing existing objects. The default action for a new object is Create. The default action for an existing action may be Replace or Skip or a flavor of Merge(which is used in tables to merge fields only, no code). The delete option in the Actions below is typically ignored. I would imagine that not many have ever used this option. 

However, if you import a Killer Object, Delete will be the default action.

If you’ve ever tried to import an object that wasn’t a Killer Object with the Action Delete, you may have received this error:

Killer Object – A NAV object that, upon import, will delete same numbered existing object.

Killer objects can be useful when you need to delete objects in client databases remotely, i.e., when the client imports fobs and doesn’t have a dev license or a license that has delete permissions on the target object(s).

Killer Objects also could be useful in a release that contains a large number of object re-numbering/naming. Instead of manually deleting objects, the Killer object will do the delete work via the fob import.

Killer Objects could be used by Addon vendors when creating upgrade Fob's and Solution Centers when creating releases that require renumbering or removing objects.

So, what exactly is a Killer Object and how are they created? It’s simple: you create an empty object. Or, as MS states in the help file: "object has size 0". And what on earth is an empty object and what is "size 0"? To create an empty object of any type, simply scroll down in the Object Designer to a new row. Enter a number and a name and click off the row. Now, export that object as a fob. Voila. A Killer Object is born.

You can also create a Killer Object via code:

  Object.ID := 50505;
  Object.Name := 'Test Killer Object Insert';
  Object.Type := Object.Type::Table;

You can easily imagine a script for this so that would create Killer Objects from a string of Object Types/Numbers in batch. Pretty cool.

Killer Object: Object with size 0. Empty Object.

Now, when the object is imported, the Action will default to delete. If the user selects Replace All, the Action on a Killer Object will change to Replace. Interestingly, it will still execute as Delete.

Here’s a simple Killer Object Example:

Download these example files:


Import “Table50900.fob” and verify that it imported correctly.
Import “KillerObjectTable50900.fob” and verify that it correctly deleted “Table 50900”

This exercise is even more exciting when you use a client license that does not have permissions to delete Tables in the 50900 range. Verify that you can’t delete the table, then delete with the Killer Object method.


Blog Tags: 



This is a totally new thing that I had no idea existed.  Good work, Jon!


Glad you liked it.


Jon, I could have used this just a few days ago when archiving 25 of old reports for a client to an unlicensed number.  I never knew this was possible!  "Someone" has a motto "Learn, try, do, repeat"....and this is one I'll definately try now that I've learned! Thanks for sharing.

Read ArcherPoint's Blog Follow us on Twitter Follow us on Facebook Follow us on LinkedIn Link to our RSS feed Join us on Google+ Watch us on YouTube