Microsoft Dynamics NAV: Diagnosing Code Problems

May 13, 2011 - 12:00 am

1424

6 min read

No one writes perfect code on their first attempt. When running hundreds or even thousands of lines of code at a time, it can be extremely difficult to determine exactly where an error occurred and what caused it. That’s why we have tools like the Debugger, Code Coverage, and Client Monitor in Microsoft Dynamics NAV.

For the most part the recipes in this article will not deal with writing your own code or writing better code. Instead, we will focus more on how you can determine what is happening with the code you have already written.

Using the debugger

This recipe will show you how to use the debugger to examine the code that is currently executing. We will demonstrate how to go through the code line-by-line and watch how values and objects change.

How to do it…

Create a new codeunit from Object Designer.
Add the following global variable:
Add the following global text constant:
Add a global function called ChangeCustomerName.
The function should take in the following parameter:
Add the following code to the function:
Customer.Name := NewName;
Add the following code to the OnRun trigger:
Customer.FINDFIRST;
ChangeCustomerName(Text001);
Customer.VALIDATE(“Post Code”);
Save and close the codeunit.
From the Tools menu in the NAV client select Debugger | Active (Shift + Ctrl + F11).
From the Tools menu in the NAV client select Debugger | Breakpoint on Triggers (Shift + Ctrl + F12).
Run the codeunit.

How it works…

When you run the codeunit, the Microsoft Dynamics NAV Debugger window will appear just like the one shown in the following screenshot:

(Move the mouse over the image to enlarge it.)

Before we get into the details of this window, we need to understand what caused it to appear. Setting the debugger to Active from the Tools | Debugger menu means that the debugger window will open every time the system encounters an error. In this case, though, we know our code doesn’t produce any errors. We want to look at it anyway so we turn on the Breakpoint on Triggers option as well.

There are five components to the debugger window. The first is the menu and toolbar at the very top. They function just like any other toolbars you’ve seen. You can mouse over each button to get a tool tip of what it does.

The second component sits right below and contains the actual code from the current object. Here you can see a small yellow arrow pointing to the first line of our codeunit in the OnRun trigger. This is the line that is about to execute. Note that it has NOT executed yet. We’ll explore each of the other three components as we move through our code.

Use the F8 key or click on the Step Into button on the toolbar. The window will now look like the one shown in the following screenshot:

(Move the mouse over the image to enlarge it.)

The yellow arrow has moved to the second line of code and the first line has executed. Notice the red text in the bottom left-hand corner. This is the Variables window (bottom left window). It lists all the variables and their values from the current object. At first, our customer variable was uninitialized because we had not executed the Customer.FINDFIRST line. That line retrieved a record from the database causing the value of the variable to change. This text will only remain red until you take another step into the program.

The next line of code that will execute is:

ChangeCustomerName(Text001);

What is this Text001 variable? If you’re unsure of the value of a text constant, or you don’t want to scroll through a possibly long list of variables in the Context window, you can add a shortcut to the Watch List (bottom right window). Right-click on Text001 and go to Add Watch. The variable will be added to the Watch List along with its current value. Go ahead and hit F8 to step into the next line.

(Move the mouse over the image to enlarge it.)

The yellow arrow jumps to the function that we just called. That brings us to our last window, the Call Stack (bottom middle window). It is important to know how you got to the code you are currently viewing. By looking at the Call Stack you can see that we were in the OnRun trigger of the codeunit and then jumped to the ChangeCustomerName function. You can click on each level of the stack to see the code for that object.

(Move the mouse over the image to enlarge it.)

You may not always want to go through your code line-by-line, though. Try hitting the F5 key or the Go command from the Debug menu. This will cause you to jump to the next function which is called instead of the next line. You will find yourself in a complete new object, the Customer table. Notice how the Context menu completely changes because the old variables are no longer in scope. They do not belong to the current object being examined.

There’s more…

One common annoyance is trying to stop the debugger. You will find yourself in the middle of debugging your code and have that “Aha! I know what’s wrong!” moment. You will click on the “X” to close the window only to have the debugger pop right back up at you.

From the Debug menu click on Stop Debugging (Shift + F5). This will stop the debugger until you turn it on again and, more importantly, allow you to continue with your development. Stop Debugging also performs a rollback of the changes that have happened to the database since you started the debugger.

Setting breakpoints

Stepping through code line-by-line or function-by-function can take forever. Luckily there is an easy way to tell the debugger to stop right where we want it to.