Category Archives: Tips and Tricks

One of the most anoying things about writing AL code in Visual Studio Code is getting warnings that you cannot fix. Simply impossible.

My “favorite” warning is this one

For almost a decade it’s been possible to sort on flowfields from code and in reports and in most cases it works fine. On larger datasets it might require a covering index for performance.

This warning is a joke because it suggests to add a flowfield to the key’s. Even if it were a normal field; in extensions you cannot influence keys in Base Application anyway.

It’s recommended to fix this per project and to do this you need to add a settings.json file to your .vscode folder like this:

The content of this file should be something like this:

{
    "name": "ForNAV",
    "description": "ForNAV Rules",
    "generalAction": "Hidden",
    "rules": [
        {
            "id": "AL0432",
            "action": "Hidden",
            "justification": "Marked for removal, be careful with this rule…"
        },
        {
            "id": "AL0254",
            "action": "Hidden",
            "justification": "Not possible to solve"
        },

In Microsoft Dynamics NAV 2016 CU1, support for VS2015 Community Edition has been implemented.

However if you do a default install of VS2015CE, the RDLC editor is not included and your report will show up as XML instead of the visual designer.
Continue reading “Tip #55 | Add RDLC option to Visual Studio 2015 Community Edition”

If you upgrade your database to NAV2016 using the PowerShell Merge commandlets and have a change to table 49 you will run into this issue.

Table 49 is the Invoice Posting Buffer table that NAV uses to create G/L entries for each unique combination of values in the Sales and Purchase documents. With the NAV2016 release Microsoft have added the Deferral Code field to this table and the primary key.
Continue reading “Tip #54 | PowerShell Merge – A clustered key can appear only once in a table”

Recently I’ve been asked to do a code review of a vertical solution. Since these are always interesting projects I cleared my schedule and planned an interview to see what it was about. I’m curious by nature.

During the interview I was told that some of their customers were complaining about deadlocks. This was going on for a while now and they did their best to look at the problem and even created a chart with deadlocks per day.

This was honestly not that much so I figured something else must be wrong. After the intake we spent some time looking at one customers system and I started up some measurements in SQL Server Profiler. Nothing fancy, just some lock events.

This showed that not deadlocks, but locktimeouts are causing the problem. From a user perspective they almost look the same.

Here is the deadlock message:

And the locked message:

But the source of the problem can be entirely different.

Simulate a (b)lock timeout

This is realatively easy. Simply create one codeunit that reads a customer record and hold the transaction with a confirm. (Never do this in real life kids)

Now simply run this codeunit twice and the timeout message will appear.

Simulate a deadlock

This is a little harder. We need two codeunits this time.

In this scenario we read two different customer records with a confirm in between.

Start both codeunits and then quickly press the confirm message. If you do this within the locktimeout window (default 10 seconds) you will get a deadlock.

Locktable

This last example also proves the myth about locktable busted. This is probably the most ambiguous command in C/AL language. It does not what it implies. It does NOT lock the table, but only locks the specific rows you read in the database.

Microsoft, can you please rename this to something that makes more sense?

Tools

You can also measure blocks and deadlocks using the tools Jorg Stryk provides for free. http://dynamicsuser.net/blogs/stryk/archive/2014/10/10/directions-emea-2014-troubleshooting-nav-2013-r2.aspx