Tip #33 | Smart Debugging

This Blog Article was brought forward from my old blog

One of the “Real life” tips I showed at NavTechDays is how to use the classic debugger smartly.

What I see people do many times is turn on the debugger with Breakpoints on Triggers

This means that the debug process wil break on each trigger it finds, meaning form & table triggers, functions and objects.

Even if you step through this process with F5, debugging a posting process like Sales wil take forever as there are hundreds of triggers that you will pass.

So what is the alternative.

The alternative is to place your own Breakpoints; this can be done in two ways

1. Via the Object Desiger

If your license allows you to edit C/AL code you can use this icon to go to the code of each object.

If you do this you’ll enter the C/AL Editor that shows the code behind the application. But if you look closer there is a hidden “column” in this editor.

If you use the “Show Column” feature you’ll see that this column even has a name: Breakpoint Column

If you select a line of code and hit F9 you’ll see that a “Red Dot” appears in the column, meaning there is a breakpoint for the debugger.

Whenever you start the debugger now without the “Break on triggers” option, you’ll see that the debugger will stop at this point, allowing you to go directly to the “suspected” piece of code.

But wait, there is more.

2. Via the debugger

You cannot just put breakpoints in the C/AL code via the object designer, you can also set them in the debugger directly, while debugging.

This allows you to set a new breakpoint somewhere down the line. This avoids the issue of stepping into all the functions and losing time.

Be Careful: This only works in the active object! You cannot step back into the previous object and add a breakpoint there.

They communicate!

The great feature about these breakpoints is that the debugger and code editor remember each others breakpoints. So if you place a breakpoint in the debugger, the red dot wil appear in the C/AL editor. This is done using the system table Breakpoint that is not visible in the Object Designer but is from the Report/Form/Page designer.

So remember using this smartly and save a lot of time in your debugging processes.

What does the open “red dot” mean?

Was one of the questions on NavTechDays, and I have to admin that I did not knew. But fortunately Lars Hammer of Microsoft was in the room and he knew. (And he should).

This allows you to temporarily disable a breakpoint without throwing it completely away. So you can quickly reenable it.

Stop Debugging

Another great feature about the debugger is the possibilty to roll-back a transaction that you are debugging. This is often useful when you have a scenario that requires a long time to setup and you don’t want to backup and restore databases just to have the same scenario while finetuning your code.

Remember this when you need to fiddle with your code and you want to see the step-by-step results.

Call Stack

In Dynamics NAV you are likely to step into a loop of objects if you debug a complex process. Sometimes you hit an error somewhere in a tree and you want to see where this code was executed from. This is where you can use the Call Stack.

In this example, Codeunit 80 was called from codeunit 81 and before that from Form 42. You can double click on an object and see which line of code caused the execution of that object. This you can then use to stop the debug process, go to the object and place your breakpoint there. Remember: you cannot add breakpoints in the debugger in a tree of objects.

Dirty Reads

Sometimes you would like to see the data that your process creates without actually committing the transaction so you can roll-back and change your code. With the SQL Server option you can do that since NAV is using the ReadUncommitted isolation level. This allows users to see data in the database that is not committed yet.

NOTE: with the introduction of buffered inserts you might not see the inserted data since that is buffered to either a find command on that table or the commit of the transaction. If you do want to see the uncoommitted data and you know where to go, then put in a simple FIND statement on a copy variable of the record object.

That’s al for today folks.