Upgrade Oil Check | Myth 1 – Add-On Fields

Recently Microsoft published an article about the new way of upgrading using PowerShell commands. It was published in NAVUG magazine, but I cannot find it online.

I am currently preparing an enduser upgrade from NAV2015 to NAV2016 Partner Beta. The new way.

So I’ve merged my objects using the PowerShell and out of almost 200 changes, only 8 conflicts, al nicely inlined in source. Guess writing Clean Code is rewarded.

This is a huge time saver! Thanks Microsoft!

Then I wanted to import the merged textfiles.

BENG, error!

This customer has multiple add-ons and I don’t have a license that covers all of them. Unfortunately this means I have to create an interim database with tables that have no code and use the Merge option in the import worksheet.

Lost an hour doing that. Bummer.

Microsoft, can you please let me add fields to base tables in any number range?

This entry was posted in General, Upgrade. Bookmark the permalink.

5 Responses to Upgrade Oil Check | Myth 1 – Add-On Fields

  1. This licensing circus has always been one of the most annoying things, when doing upgrades. Why would that have become easier? It’s always been a problem, although I don’t remember anyone writing about it the last 8-10 years. Whish that they could do “something” to avoid it. Both via powershell and “natively”.

    Liked by 1 person

  2. Jeremy Vyska says:

    Totally agreed. Addons are the biggest time sink for upgrading, which is a pain here in Sweden. There’s an ISV solution that adds a ton of Swedish specific functionality (bank integration being a big one) that Microsoft’s SE database doesn’t have. So EVERY upgrade here is a nightmare of merging.


  3. waldo1001 says:

    Don’t know how many times this has been put to the table – among lots of time by me personally. Even last year when I tested the PowerShell CmdLets, it has been put on the table again – together with the conflicting ControlID’s … same shit, different day.
    Every time: we’ll look into it. But no result whatsoever.

    Liked by 1 person

  4. Jeremy Vyska says:

    Heck, at this point, just a Powershell Cmdlet that strips all the code from Table object text files would be a massive speed boost. You clever scripters could easily generate a multistep process then that would take care of it all.


  5. Kowa says:

    The “Table Washer” may not be available as a Cmdlet, but at least as a separate tool.
    Useful as it is, it won’t help you with the licensing range issues though as long as only fobs can create new fields outside the permitted range.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s