NAV2016 CU1 | The AltSearchField field property does not work as documented

Whenever I teach a class I always talk about boat anchors and my favorite one is the AltSearchField property.

Luc van Vugt describes it on his blog:

It is one of these features that we inherrited in the Windows version from the Dos version, but it never worked in RTC or other modern clients. This is why I was surprised to see this in the list of fixes for CU1 of NAV2016:

376291 The AltSearchField field property does not work as documented.

After investigation it looks like Microsoft removed the property from the options in the Development Environment.


So this is a boat anchor that is now fixed. However…

If you export the G/L Account table to txt it is still there.


So it is actually a hidden property.

Thank you Microsoft for starting cleaning up NAV!

I have to start looking for a new favorite boat anchor.

Using Argument Tables | Introducing Overloading in Dynamics NAV

Last year I did some videos about organizing code in Microsoft Dynamics NAV which I put on my YouTube channel. I wanted to do more, but got occupied by writing a book about learning dynamics NAV patterns and organizing a global set of classes around this subject.

Let’s continue where we left off and discuss the possibilities and challenges of implementing the arguments table.

Let’s go into it.

At the end of this blog you will be familiar with the Arguments table pattern, why we need it in Dynamics NAV and what are possible negative side effects.

Problem Definition

Within our C/AL programming language and programming in general we have some challenges.

Using to many arguments in a function

When creating functions we sometimes need a lot of parameters to give the information we require. Sometimes these parameters are optional, only required in some scenarios. This makes calling them quite hard. The code becomes less easy to read, sometimes spread across multiple lines.


Hard to change signatures

When refactoring code it is hard to change signatures of functions when they are called in many places of the system. Think about the Functions that create reservations for example. When changing the signature of these function you might end up changing and endless chain of codeunits.


No Function Overloading in C/AL

Our beloved language does not support overloading. What is that? I had to look it up too the first time. Overloading means creating functions with the same name and meaning that take different parameters effectively allowing you to be more flexible in your code.

For example creating a new DateTime in DotNet can be done in 12 different ways with different parameters effectively giving the same result, a DateTime.


Duplicating Option Definitions

Lastly, when calling functions that take an option field as parameter we have to duplicate the option value in order to make the code easy to read. And option values are hard to maintain anyway.


These challenges can be solved by grouping commonly used arguments in a single table and use that table as the parameter of a function. This is effectively using a table as a class.

Let’s look at some examples of candidates in our product

The legacy code of Dynamics NAV is full of examples, but let’s discuss two that you are bound to hit if you start working with the product, even if you don’t deep dive.


This function in codeunit 7000 is called to calculate a sales price for an Item. It uses 10 parameters.


This function in codeunit 365 is called to format an address in the system

Changing the signature

Imaging adding a field to this function, or change a datatype. The amount of code affected is pretty big and if you need to parameter only for one specific case you end up changing a lot of code for no purpose.


Fortunately the compiler finds all instances where the function call is incomplete, but that does not mean we should use that to change all of them.

Let’s also make sure we understand that the sheer fact that NAV legacy code has these functions it is ok to do so. It does not match the basic principles of clean code.

The Argument Table

So the solution is to create a single table that holds the contract for the function. This would be similar to creating a class in DotNet and using that class as parameter.

When we add new fields to the table, we effectively do not change the signature of the function hence this acts as overloading allowing optional parameters to change the behavior of the code.


Examples in Standard Dynamics NAV

What if I told you that this one of the oldest patterns in Microsoft Dynamics NAV, dating all the way back to good old Navision Software. Would you believe me? I guess not, but it is true.

All codeunits that are used to post Journals are effectively argument functions. We use the Journal Line as an argument table to call into the posting routine. Imagine the effect if posting routines had all these fields as parameters.


When we call one of these codeunits nested inside another transaction we never actually insert the journal line in the database. We merely use the record variable as a placeholder in memory for the data.

Side effects

Although in my personal opinion the arguments is one of the greatest patterns to write clean code, there are some side effects

First off we need to write code to populate the arguments table. This requires us to write extra code we don’t need if we just call a function with let’s say 10 parameters. It does make the code cleaner and makes it intention easier to understand.

Also, the fact that the compiler does not catch adding a field to the table as a signature change can be a downside. Who has not abused this feature as “where used”. We would really need where used in order to perform a risk analysis when adding arguments.

Last but not least, one of the basic principles of events will be broken. The new events in NAV2016 have a built in warning system if a parameter that I inherit no longer exists. This mechanism does not understand if I delete a field of an arguments table. The extensions have the same challenge.


Let’s look at an example. In NAV2015 the development team decided to implement email as an arguments table. This is table 9500 Email Item.

This table has all fields we need to send emails, as well as functions to send the email. The validation logic of the fields can be used to perform checks on the values. How nice and clean is that.


The arguments table is used in Codeunit 260 Document Mailing. Here you can see the coding that is required to use an arguments table.

A new, nice and clean way of writing C/AL code.

Naming Recommendations

When using arguments tables, I recommend adding the keyword “arguments” to the name of the table. This makes it one of the only, if not the only plural table name in Dynamics NAV.

Licensing Considerations

In essence Argument tables can be outside of a customer’s license file since we never insert data in the SQL Server database. However, when you want to use functions as methods of the arguments table it needs to be licensed. Reason for this is simple. The licensing engine is not aware that you want to run code that is tied to a temporary table, you might for example call code in a Production Order when running Business Essentials licensing. To make this work, Microsoft first needs to add a table type “temporary” to the properties

Want to know more?

I will create a video on this too soon. The Arguments Table is also part of my new book.

Learning Dynamics NAV Patterns

ANNOUNCING: New Book | Learning Dynamics NAV Patterns

Since Packt Publishing put it on their website, I might as well reveal a secret project I’ve been working on for the last couple of months, almost a year.

My new book Learning Dynamics NAV Patterns is about to be released. I am in the final stages of processing reviews.

You can order the book here.

The book is a written version of the Master Class for Application Architecture and Patterns I am currently teaching across the globe and contains a lot of information about the Dynamics NAV DNA in a structured, easy to follow way. Things that have been in the product, some 30 years, some only one or two releases.

It also contains coding best practices, anti-patterns and refactoring methodologies and finaly a real world example of how to apply patterns while architecting a solution, working with Delta files and using Visual Studio Online to host your IP in the cloud.

The book is a more abstract and technical version of my first book Microsoft Dynamics NAV 2013 Application Design. All the things I learned from being part of the Design Patterns project and Partner Ready Software have been applied to this hands on bundled work. I would like to thank all other members from the teams for their inspiration during the meetings and brainstorm sessions and I hope they enjoy the way the efforts are combined and for everyone to grab although the book is my view and solely my opinion on the matter. The book would have also been worse without the reviewers. One in particular who shall remain anonimous had a big impact on the final version.

I’ve also read countless articles about clean code, object orriented programming and design patterns. I can’t mention them all but I would like to thank everyone for sharing their views and vision with the world.

Please (pre) order the book and enjoy.

Marije Brummel


We’re back to be found | Dynamics NAV Community

Oh my, I was almost ready to blog about it. We were completely lost!

“What do you mean?”, I hear you say.

Dynamics NAV is, as far as I know, the only product on the community website with a Wiki and with one of the last updates, we were gone missing.

Fortunately we are back and on a really nice place.


Thanks Bogdana and Dustin for this nice spot.

Remember, the wiki is a community project. If you want to contribute, don’t hesitate to sign up!

Design Patterns YouTube Playlist | 30 Videos

With the recovery of a lost video at Microsoft, the Design Patterns YouTube PlayList has 30 Videos now.

23 of these videos are part of the How Do I series and co-sponsored by Microsoft. 7 videos are created by me.

You can find the PlayList on my YouTube channel: Here is the link:

Until a year ago I was unfamiliar with YouTube and video making but it is surprisingly easy to do and sends out a very clear message.

The playlist includes an hour long introduction to the concept of Design Patterns

Workshops (Advertisement)

If you want to learn more about how Design Patterns can help you improve development of Dynamics NAV in your company we have started a series of workshops together with regional MCT’s.

The first region we host is North America. On March 19th and 20th we do Atlanta with Mike Doster and on March 23rd and 24th we do Toronto with Floyd Chan.

Next up will be Europe with probably Belgium, The Netherlands, UK and Austria. I am still looking for an MCT in the UK to work together with.

Quiz: Can you see the difference between these two images?


[PRS] Design Patterns that should be [made] obsolete [by Microsoft]

Yes, this blog has a double title. Every now and then you need to do a little self reflection. Two weeks ago I was in talking with my fellow PRS member Soren Klemmensen and we discussed the fact that in the list of object oriented Design Patterns that we brought to Dynamics NAV there are a few that could be built in or better integrated if Microsoft would help us a little.

Ok, if you read this and think, what does this guy mean, then I should tell you some background first, otherwise just skip this part.

For the last 4 or 5 years ago we have been working on the Design Patterns project. Next to documenting the existing patterns with Microsoft we also tried to look at some best practices to better code in Dynamics NAV. They are also design patterns, categoriesed as implementation patterns, meaning the way you structure code.

Examples of these patterns are:

  • Class, Method, Property (aka Agents/Actions)
  • Natural Language Programming
  • Encapsulation
  • Facade
  • Hooks
  • Interfaces
  • Surrogate Keys

You can learn more about these patterns on my YouTube channel.

While most of these patterns have nice names now, we actually changed them quite a number of times. Natural Language Programming was once called Readable Code and Encapsulation was called Atomic Coding. The Class, Method Property has two names as well. Reason for this is that we learned during the project that most of these concepts are well known in computer science and object oriented programming. We were reinventing wheels.

Dynamics NAV has a realtively basic development environment that does not allow us to do things that Visual Studio and C# or other languages do. On the other hand it has lots of things that C# does not have that we can take advantage of.

This can come in handy when trying to make a couple of these PRS design patterns obsolete, smarter or built in the environment. One of the reasons we can do this is becuase C/AL and C/SIDE are very metadata driven.

So what patterns can be made obsolete

Class Method Property (aka Agents/Actions)

This pattern teaches us to make all functions that you can perform on a table a member of the table and if complex enough put inside their own codeunit.

The reason why we thought of that is actually a bug in the symbol menu. The symbol menu does not understand code outside the contect of the variable you define. For example: if you define a variable of the type Sales Header, it does not show that we have a codeunit that takes this record as a parameter and posts it.

If that would be the case, we would probably have to rethink this pattern. I have implemented this pattern at one of my solutions where we have a table that is more or less the core of an application. This table now had douzens and douzens of functions. I can honestly say that this does not improve usabilty more than loosely coupling the codeunits to tables.

It would be easier if NAV reads the metadata and helps with the symbol menu. That would save a lot of functions on the table that are then obsolete and actually a hassle to maintain.


This was the example I thought about yesterday when I did an introduction to design patterns workshop for NAVUG USA. I was talking about encapsulation and override. Most languages allow programmers to override functions in a class. NAV does not.

With PRS we found Facade as a solution for that, but it is actually wrong to suggest to implement a facade for each function you create on the table. Think about it. You would dramatically make your code more complex than required.

Facade is a great pattern! It exists in object oriented world and it should be implemented by design if the architect expects functional requirements to override the function. The typycal example is weighing bridges where every customer has their own hardware and has a custom interface. This is what facade does great.

C/AL should allow programmers to override any other function at design when required without the orriginal architect anticipating every move. Other programming languages allow that.

Surrogate Keys

This is the newest member of the PRS design patterns and as most other patterns it started its life with another name. Unique Record Identifier.

In dynamics NAV most tables are connected through the primairy key, for example comments. Comment tables have complex primary keys to be able to connect them to each table in NAV.

The idea is to add a single unique key to each table in NAV so we can connect to other tables using a single unique key. Think about the possibilities to add factboxes using this to each table in NAV without thinking.

C/SIDE can add this automatically for us.


Some design patterns can be improved with what I think are relatively small changes to C/Side. We should always self reflect and realise that some things we do are actually workarounds.

Implementation Pattern #2 | Natural Language Programming

If you want to read the first article about Implementation Patterns, here is the link.

If you prefer a video, it is on YouTube. The blog starts at 2:20 after a general introduction.

Natural Language Programming

I hear what you are thinking. A scientific concept like this, in C/AL. Yes, in C/AL.

Scientific Approach

If we look at Natural Language Programming as a concept there is first of all the scientific approach. Programming computers in natural English, or any other language, preferably via speech recognition. However, there is a lesser science fiction approach to the concept.

Multi Level Coding

This is multi level coding. Splitting the nerdy code, from the readable code.

Natural Language Programming has actually been implemented in some way in SQL and COBOL, it’s not new and we’ll try to apply it do Dynamics NAV.

If we look at SQL server syntax, you can see that readability is implemented in the language.


With Dynamics NAV we don’t have that, we have SETRANGE and SETFILTER and FIND. Also with SQL code get hard to read once you start adding business logic.

The approach we would like to you take when we talk about Natural Language Programming in Dynamics NAV, is to write two layers of code Readable Code and Nerdy Code. These layers should be separated.


Traditionally, if code is to nerdy and hard to understand the programmer will add comments. And if one programmer cannot understand the others code, the feedback will be, he forgot to put comments in the code!


This is untrue, comments are evil and should always be avoided.

Let’s look at an example.

The development task we will give our programmer is to create a script for a very popular customer who always buys the same item. A side board.

Instead of coding away, our developer starts thinking what steps need to be implemented.


So this is the code we end up writing.


Although this is very understandable code, it does nothing. We need an extra layer, the nerdy layer.


The nerdy layer contains the actual C/AL code that does the heavy lifting.

But wait! This is not all, there is a bonus. This makes debugging accessible for consultants and end users.

Even though general rules mostly say debugging is for developers, if all hens is on deck, everyone will start debugging.


And when Natural Language programming is implemented, this will have the same two layered approach and we can step over all the code that does not contain errors.

So where do you start with implementing this.

There are two approaches.

The first is to start writing the functions and then write the code. This is the preferred way.

The second option is to start with the classic approach and then break it down and create smaller pieces.

Remember that when loops are required, you need to create a very logical function name since you cannot see the functions inside the loop from the initial workflow. To support this pattern the function names can now be 132 characters.

There are two enhancements to the C/AL code editor that would improve using this pattern.

The first is to select a few lines of code and create a function from a right mouse click. (Thanks to Soren Klemmensen for the idea)


The second would be to see from the editor that a function has details or subfunctions.


As a reference video I would encourage watching How Do I Implement the C/AL Coding Guidelines which will be published in December 2014.

Remember, write readable code, and nerdy code and separate them. This will enhance readability of your code and improve maintainability.

MiBuSo: We have Design Patterns forums now!

Let me start by thanking Luc and Alain for making this forum reality.

The Dynamics NAV ecosystem is becomming more and more aware of Design patterns and I get almost daily questions about them via mail or other channels.

These forums are meant to share knowledge and ask questions.

You can find descriptions about Design Patterns on this Wiki: … fault.aspx

Or on YouTube: … freload=10

Let’s make this happen!

Happy coding.

PS: I am moderating the forum, so please be nice. 😉

Implementation Pattern #1 | Classes, Methods and Properies

So last week in this post I promissed you to publish the implementation patterns that help you structure your application to achieve repeatable and upgradable solutions that are easy to understand and maintain.

Not a big reader? You can watch the video of this blog post!

This is the first pattern and one of the most fundamental elements to understand before proceeding with the other patterns.

We will talk about ising classes, methods and properties in C/AL, a functional language.

Classes, Methods and Properties are elements of C#, an object oriented programming language. However there are certain elements that we can take from that language and map them to Dynamics NAV and make our daily lives easier.

This week I wrote two other posts in a series about Dynamics NAV and C# that discuss the same concept from another side. If you haven’t done so I recommend reading them first.

Dynamics NAV in C# | Part 2 | Classes (Updated)

Dynamics NAV in C# | Part 2 | Classes (Continued)

And here are the two other posts about C# and Dynamics NAV:

Dynamics NAV in C# | Part 1 | The Differences

Dynamics NAV is moving to C#, get ready to follow!

Let’s talk about the Pattern

The problem we are trying to solve with this pattern is the loose connection between tables in dynamics NAV and what you can do with it in other objects such as codeunits.

If we look at an example, we have the customer table, and a function in Codeunit 365 Format Address.


If we want to format an address in a report, as a developer I need to know that there is something like Codeunit 365, declare it as a variable and call the right function. There is nothing in Dynamics NAV that helps me find that function.

Another example, the sales header. With this I can call the post Codeunit or the Release Codeunit.


However, when I look at the sales order page, we see again that the codeunits are called as variables.

What would this look like in C#?

Let’s compare this to object oriented programming, C# and classes.


In C# the customer table would be a class and the fields would be properties that have a getter and a setter. The class has a method FormatAddress, and this calls out to a generic class.

Our Sales Header and Sales Invoice would also be classes. Probably in pure C# you would increase the object orientation with inheritance, but let’s leave this a simple example.


With a Sales Header I would be able to use the Method Post and with the Sales Invoice I could call the FormatAddress again.

Let’s do this in Dynamics NAV!

So what if we do this in Dynamics NAV.


We would create a function on the Customer Table called FormatAddress, and then on our report.


We don’t have to know the Codeunit anymore, but browsing through the Symbol Menu, the equivalent of Intellisense in the C/AL editor, I would see that a function FormatAddress exists and I just use it from my report.


The Table is the class, the Function is the Method and a Codeunit is a Class.

The same would work for the Sales Header.


This would have functions release and post. And on the page I can just call the functions.


This pattern has a number of advantages. First of all there is a clear intention of the programmer. Everything you can do with a record in the table is clearly specified on the object.


It reduces the learning curve for new developers, since by just looking at the functions in the symbol menu we can learn what we can do with the records in the table.

We can actually use the symbol menu. Using this pattern would make creating a Codeunit as a variable on pages and reports wrong. If you see a Codeunit on one of these objects, it is an indication that this pattern is not implemented.

When working on methods, developers have less chance of overlap changing the same object. This makes merging easier when the branches come together.

And it actually allows us to do versioning of business logic. This concept will be explained in another video or blog post.


There are some downsides too. If you create a Codeunit for each function, you get a lot of objects making managing the application less easy. Also having more than a hundred functions on a table does not exactly clarify the intention either.


Lastly if you call a table function from a page, the Go To Definition does not work which is highly annoying.


To avoid too many codeunits in your application, you might use the rule that if a function is less than 5 or 10 lines of code, you can write the code in the function. We’ll touch on that too when we will talk about natural language programming.

2014 Conference season is over, NAVTechDays rocks | What’s up next ?

With NAVTechDays 2014 last week, the conference season for Microsoft Dynamics NAV is officially over.

From the perspective of a presenter, NAVTechDays is just amazing. At a cinema with a screen the size of a small house and hundreds of attendees is an experience that’s next to nothing.

I’ve already wrote some articles about what I did in Antwerp. Just in case you haven’t read them yet, you can find them here, here and here. I also recorded a video.

I had to promise Arend Jan Kauffmann that my next blog post would actually contain useful information, so hopefully it did.

Why Do You Attend All These Conferences…

…and what does Microsoft pay you? That is a question a lot of people ask me. Traveling to 6 events across the globe in 10 weeks has some serious impact on your life.

First of all, let me release you from one dream; Microsoft does not pay anything.It just does not work that way. Even if you are an MVP you are on your own. And just because you are an MVP, doesn’t make you a good presenter or a good teacher either.

For me the reason to do it, is to meet a lot of people and to get a chance to evangelise a wonderful product. The only selfish act is that paying my mortgage depends on the continuous existence of the product, so I might as well help keeping it so.

So what’s next?

I am inspired to do a lot of blogging and some videos. First of all I want to continue with my C# series that I started. I have learned a lot of C# during my trips. Even last week during Vjeko’s Mere Mortals session I got some inspiration to write an article.

From a Design Patterns perspective we are getting ready to a complete package of Architectural, Design and Implementation patterns. We have a good list of patterns on the wiki and almost 30 videos.

Together with the object-oriented methodology we presented during the writing repeatable software session we have a complete package what deserves more attention. You can expect that coming.

What about Partner Ready Software?

When we started PRS in 2011, the intention was to brand a thinktank and community initiative. With the design patterns project maturing one could argue about the value of such a concept.

Truth is we don’t know yet what will happen. There are a few options that we are currently discussing that have different futures for the brand. I’ll keep you updated as things get more clear.

So now…

…back to work all of you, you already wasted enough time reading this…