In the new version of Microsoft Dynamics 365 Business Central, there are also some changes to the debugging and launch.json configuration.
Launch specific company
Having more than one company within your development environment is rare. However, having more companies in a sandbox environment or in a production environment is not so unusual. In that case, if you needed to test your modification or debug something in a different company, you had to switch companies manually. The new version brought a new launch.json parameter “startupCompany” where you can specify the name of the company that should be opened.
{
"version": "0.2.0",
"configurations": [
{
...
"startupCompany": "COPY COMPANY"
}
]
}Skip errors in the Try functions when debugging
Debugging some core processes could be really hard, especially if there are try functions. A quick reminder what is the try function – The Try function in AL Language is a special type of procedure in which any raised Errors are suppressed. Instead of showing the error message, the functions return true if there were no errors or return false if at least one error has occurred.
Until Business Central 2022 wave 2, if you debugged with breakOnError = “true” even these errors caused the debugger to stop at the line where the error occurred.
With the new version, this parameter has changed. Values true/false are still available, however, they should not be used anymore as they may be deprecated in the future. “True” should be replaced by “All”, and “False” with “None“. Furthermore, there is a new value “ExcludeTry” that behaves in the same way as All EXCEPT for errors in try functions that do not stop the process. In my opinion, it could be really helpful!
{
"version": "0.2.0",
"configurations": [
{
...
"breakOnError": "ExcludeTry"
}
]
}BreakOnRecordWrite only for non-temporary records
Similarly to the previous one, there is a new option for the BreakOnRecordWrite parameter – ExcludeTemporary. With this value, the debugger no longer stops at each record modification – it stops only when the “real” record is modified. It is once again a great enhancement, as you usually do not want to debug writes to temporary records, but only to records that really store data.
True/False are also still available, but as with the previous one, they should no be longer used but replaced by All/None.
{
"version": "0.2.0",
"configurations": [
{
...
"breakOnRecordWrite": "ExcludeTemporary"
}
]
}View SQL locks during debugging
One of the changes I like most is the possibility to see SQL locks directly in VS Code during debugging. SQL Locks are available directly in the Business Central client for some time, but to see locks when debugging, you had to open another client session and check locks there. It was really annoying, but now it is really simple – it is visible in the “Database statistics” section in VS Code and automatically updated when stepping through the code.
