Using the Script Debugger in Runtime Mode

  • Article

David Meego - Click for blog homepageYesterday, I handled a support case that asked about using the Dexterity Script Debugger at runtime and whether there was any performance issues having the Debug menu enabled when it was not being used to perform any logging.

What we are talking about is adding the ScriptDebugger=TRUE setting into the Dex.ini to enable the Script Debugger at runtime mode as described in the Knowledge Base (KB) article below:

Now, this facility is really useful for developers to test their code in a live environment, especially if they are working with cross dictionary development techniques which cannot be tested using the Dexterity Test Mode from the Dexterity Development Environment. If you include the debug information and source code in a dictionary, you can use breakpoints and pause the code and look at variables and table buffers, just like in the normal development environment. In fact you can do everything except edit the scripts.  You can also use the methods in the quick tip post below to swap dictionary context between dictionaries if you need to work with more than one dictionary at a time:

So, to answer the question: There is no performance issues caused by having the Script Debugger active (so that the Debug menu is displayed).  If you enable logging or profiling then there will be a minor performance overhead as the runtime has to perform additional work.

BUT....

While there might not be performance issues caused by enabling the Dexterity Script Debugger, there are other issues caused as side effects. It is these issues which are the reason that it is not recommended to leave the Script Debugger enabled in a live environment. 

  1. The application toolbars will not hold their positions and will be "messed up". (Yes, I know this sometimes happens anyway.)
     
  2. Internal Debugging messages and errors can be displayed if the Show Debug Messages option is checked.  This can stop scripts from completing, if (for example) they receive a string overflow error.  These messages should never be seen by an end user.
     
  3. The Shift-F11 function key used with Visual Basic for Applications (VBA) will not work as it is already assigned a different use under the Debug menu, see the post below for more information:
     
    Why does VBA's Shift+F11 not always work? 

So, if you want the ability to capture the Dexterity Script Logs and Dexterity Script Profiles from the live environment, then there is a better alternative.

You can use the Support Debugging Tool and its Manual Logging Mode to capture the Scipt Log and Script Profile as well as the DEXSQL.LOG with a single key press.  You can do this without having the Debug menu enabled and without needing to change any Dex.ini settings.  You also will not need to exit and restart the application.  You can precisely start and stop the logging either side of the issue you want to capture. AND.... if using a terminal server, as you are not enabling DEXSQL.LOG logging via the Dex.ini, it will only be logging SQL communication between the application and SQL Server for the current instance of the application. You will only have your user's actions captured rather than every user on the terminal server at the same time. The Support Debugging Tool remain dormant until needed and offers many other great features for debugging, development, support and administration of Microsoft Dynamics GP.

Note: Please don't confuse the Dexterity Script Debugger (Debug menu) and the Support Debugging Tool. They are not the same thing, but the Support Debugging Tool does use some of the Dexterity Script Debugger's functionality in its features.

So to sum up: The Dexterity Script Debugger is a developer's tool and should not be left enabled in a live environment.  If you want logging facilities, use the Support Debugging Tool's manual logging feature instead.

Hope this is useful. 

David