The debugger starts from the Dynamics NAV Development Environment. The user with which you are logged in must be assigned as a user in SQL Server. Go to Tools | Debugger | Debug Session.
The Session List page will open, as shown in the following screenshot:
The session you select can be any of the following:
Place the cursor on the line corresponding to the session you want to debug and then click on the Debug button from the ribbon bar. You can select your own session or any other session from any other user. You can also click on the Debug Next option to debug a session that is not on the session list. The next session can be a session of any client mentioned previously.
The user won't be able to work with his/her session while you are debugging; therefore, whenever possible, open your own session and debug your session. If you cannot reproduce the bug because of user setup conditions, debug the session of the user that is encountering the problem, but remember to warn him/her.
The Debugger page will now open, as shown in the following screenshot:
Note that the Code area is blank. You can still work with the session you have selected, but no code appears on the debugger. There are three options to start to debug code:
You will notice that on the Debugger page, you can only see the Code area, but you are missing two important parts that you will need to debug. The Call Stack FactBox is a list that shows the functions and triggers that are currently active. The Watches FactBox will allow you to select variables to see their current value.
This can be considered as the debugger setup. From the Debugger page, click on the Break Rules icon found on the ribbon bar. The Debugger Break Rules page opens, as shown in the following screenshot:
In Dynamics NAV 2016, you can find three basic options on the debugger feature:
INSERT
, MODIFY
, MODIFYALL
, DELETE
, and DELETEALL
. By default, the debugger is not set to Break On Record Changes.If you explicitly set a breakpoint in codeunit 1 or in code that is called from codeunit 1, the debugger breaks execution when it hits the specific breakpoint, regardless of whether you have selected the setting to Skip Codeunit 1.
By default, the debugger is set to Skip Codeunit 1.
If the debugger is set up to Break On Error, the best way to determine the cause of a runtime error is to disable all breakpoints and click on Continue. The debugger will automatically stop the execution of the code when it encounters an error.