Those of you that know me will know that I started working on extensions pretty soon after we upgraded to Dynamics NAV 2018. That has led to a recent go-live of our first two extensions. One is a smaller one, the second is pretty sizeable and has to do with paperless order picking and automatically printing packing slips and address stickers from our new packing machine.

Now during the development phase I messed up. And as I believe in owning my mistakes I will share this with you all.

What nobody told us when we started development is that once your extension is in production fields in tables and table-extensions cannot be changed. At least, not without uninstalling the extension and deleting all data in the entire extension. And deleting all the data in this extension is not going to make our  warehouse manager very happy. At all.

And yes, I do know about upgrade codeunits and yes, I do know I can create a new field and make the old one obsolete. Only, there was no data in this table yet. So there was nothing to upgrade. I just wanted to change the order of my fields.

So, what happened? After the go-live of the first version I started development on the interfacing between the PLC of our packing machine and Dynamics NAV. A fun job for which I required a new table. Now during development this table was somehow taken into production after a bug fix. A simple mistake that can happen. But what happened then is that I changed the fields in the table. Not a problem in Dev and Test as there is no data. But when I wanted to go to production all hell broke loose. Fortunately for me it was a simple table and with some minor changes we went live anyway. But those fields I wanted to change will bother me forever now.

So, lessons learned. First, beware of what goes to production. It is easy to build the wrong version of an extension.

Second, create small extensions with dependencies. Plan and design well.

Third, don’t break API. Wait, what? API? I just changed a table. Well, in our brave new world a table is an API as other developers can subscribe to events in your extension. And the first rule of creating API’s is that you do not break them. Ever.

And that raises a pretty serious question. We are all happily subscribing to events in Standard Dynamics NAV. Or DYN365BC or whatever the marketing demons want to call it these days. What if Microsoft breaks their own API? We all know how easy it is to change a codeunit right? Bye bye easy upgrade.

Food for thought.

In the meantime, feel free to make fun of me. But please learn from my errors.

Some further reading:

https://github.com/Microsoft/AL/issues/1499
https://docs.microsoft.com/en-us/azure/architecture/best-practices/api-design
Photo by chuttersnap on Unsplash

About the Author René Brummel

My driving force is the will to learn. Every day brings its unique challenges, my goal is to rise to each challenge and learn from it. My professional expertise is the streamlining and optimization of business processes. My experience ranges from software development (I know AL, C/AL, C#, .NET, Visual Basic etc) and implementation to business processes optimization, project management, training, and coaching. At the heart of what I do lies my vision, “sustainable change comes from conscious choice, made out of free will”. In my spare time I am a member of Bikers Against Child Abuse. B.A.C.A. helps abused children to no longer be afraid of the world in which they live.

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 )

Google+ photo

You are commenting using your Google+ 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 )

Connecting to %s