Dynamics NAV 2013 comes with a completely redesigned development experience. One of the nicest new features is the innovative debugger. When I was looking for information that covered the new debugger, I found a lot of small articles that simply said it was more powerful and would debug any c/AL code. I wanted to understand it more, so I installed it to play with. I understand that not everyone has that luxury so I wanted to write a more in depth article to help you decide if it is truly worth looking at. Even if you are not a developer, this feature could prove valuable to you and should be considered when comparing new systems or when taking into account an upgrade proposition. The features in this debugger will drastically cut trouble shooting time and help to identify issues quickly.
The first indication of the power of the redesigned debugger is that it allows you to choose what session you would like to debug. This opens up the ability to debug any C-Side code anywhere in the application. This includes pages, reports, and xml ports and gives you the ability to debug objects running under any user (including the application server). If that doesn’t excite you enough, check out the walk through of this fantastic tool and see what it can do.
Open Microsoft Dynamics NAV 2013 Development Environment
Open a database by using the File -> Database -> Open option
From there click on Tools -> Debugger -> Debug Session or click Shift+Cntl+F11
This will bring up the Session List window shown below.
All sessions attached to the chosen database are shown in the session list [Session.1]. If you choose a session and click the Debug option [Session.2] or press Cntrl+Shift+S a debug session window will come up waiting for an action from that session. Without even starting to debug a session, you can get critical information about the sessions that are attached to a db such as:
· the user id attached to the session
· what type of client they are attaching with
· what server they are coming from [Session 4]
· if they are currently being Debugged [Session 5]
· if they have been Debugged [Session 6] while this session of the Debugger has been open
· if SQL Tracing is enabled [Session 8] (SQL Tracing is covered at the end of this post).
If there was already a break point set, the user could not just move through the code until they hit the break point.
The options shown in [Debugger 2] are to step into, step over, and step out all pertain to functions that you are currently in when sitting on a line. They are pretty standard with any debugger and not new to the debugger in 2013.
The same goes for the options in [Debugger 3]. Continue starts the code and continues to the next break. Break will stop the code at the next statement and is good to turn on when you are sitting in a position on a page and just want to know the first thing to run when you start and action. Stop, stops the entire debugging session.
This brings us to the options in [Debugger 4]. Toggle is common and will toggle a break point when you are sitting on that line in the code window. This is also accomplished with F9. Set/Clear Condition is a bit more exciting. When you are on a break point and click it you will see the window to the right. It allows you to put in an expression to be evaluated and decide if the code breaks there or not. If a break point has a condition set, it will display a plus inside the circle
In addition to any break points that are set, Break Rules [third option in Debugger.4] are additional options for when to break in code. The rules are Break On Error, Break On Record Changes, and there is a checkbox to indicate if you want to debug codeunit 1 or not.
Skipping codeunit 1 is important when walking through code. It prevents you from having to run through all the system and change log checks so you can simply step through the code block you are concerned with.
The next option in [Debugger 4] does exactly what it says, it disables all the current breakpoints you have set. An easy button when you want to continue to the end but you do want all the code to execute so you don’t want to cancel your debugging session.
The final option in the [Debugger 4] set of options is the ability to show a full list of all breakpoints currently set. This is done with the Break point list (Shown to the right). The options are self-explanatory and all do exactly what they say. This is a very nice feature to be able to manage all of your break points and enable/disable different ones with each run through the code. Just the ability to see them all in one single list makes debugging much more transparent and straight forward. No longer do you need to run the code to a break point then disable it when you do not think you need it for this run. In addition, if you do happen to know the object and line number you wish to set a breakpoint on, you can also add a new break point within this list.
So that takes care of our debugging options when we know the session we want to debug but what happens when we need to debug a web service call into NAV or a NAS session? Well, that is where [Session 3] option comes into play. It says debug next and it is used to debug the next session that comes on line. So if you want to debug a Web Service call, you will need to find a time when you can isolate the calls in and then turn this on, start your web service call and it should be the session caught. Same for NAS or any application that uses session start, just isolate the db, then start the service or process and capture the next session that appears.
This brings us to the last option we will discuss in this article. Full SQL Trace [Session 7 and 8]. SQL profiler is something I have used a lot of since I started with NAV. Generally to understand permissions but occasionally, it has been instrumental in solving issues. However useful, it has also always been a little frustrating because of the amount of obfuscated code. When used with Profiler, the Enable Full SQL Trace button at the top coupled with the corresponding check mark on each session you want to trace. There is a great article on how to do this on the Dynamics NAV team blog here http://blogs.msdn.com/b/nav/archive/2012/09/18/example-of-how-to-use-sql-tracing-feature-to-profile-al-code.aspx