Yesterday, 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.
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.
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, I know to some extent that enabling Script Debugger on Terminal Services GP Client would be disaster at times. But I don't know it's exact impacts. Is it really not advisable to enable it on TS client environment? Thanks.
I don't know of any reason that enabling the Script Debugger would be any different on a terminal server. It is best not to use it in a live environment, it was only designed for testing and development purposes. Anyhow the Support Debugging Tool can provide much of the same functionality without side effects.
Posting from Mark Polino at DynamicAccounting.net
Posting by Vaidy Mohan at Dynamics GP - Learn & Discuss
PLEASE READ BEFORE POSTING
Please only post comments relating to the topic of this page.
If you wish to ask a technical question, please use the links in the links section (scroll down, on right hand side) to ask on the Newsgroups or Forums. If you ask on the Newsgroups or Forums, others in the community can respond and the answers are available for everyone in the future.