Views:

INTRODUCTION
This article describes how to use the Dexterity Script Debugger to trace bugs and performance issues in Microsoft Dynamics GP and in Microsoft Business Solutions - Great Plains.


More Information
About the Dexterity Script Debugger
When you try to identify the cause of a bug or understand why some functions have slow performance, support teams typically request a Dexsql.log file. The Dexsql.log file shows all the communication between the application and the computer that is running Microsoft SQL Server. However, the Dexsql.log file does not show the internal processing that occurs in the application. Additionally, the Dexsql.log file does not show access to the tables that are not based on SQL Server, such as local temporary tables.

The Dexterity Script Debugger uses two methods to trace what is occurring in the code:

 

  • The Script log (Script.log) shows all the scripts that are called. The scripts are shown in their hierarchy and with their parameters.
  • The Script Profile log (Profile.txt) lists all the scripts that are called and all the tables that are referenced. The Script Profile log also lists the times the scripts were called and the times the tables were referenced. The Script Profile log also lists the milliseconds each action took.
How to enable the Dexterity Script Debugger
To enable the Dexterity Script Debugger in a live run-time environment, and to generate the Script log and the Script Profile log, follow these steps:
  1. Change the Dex.ini file by adding the following lines to the [General] section.
ScriptDebugger=TRUE
ScriptDebuggerProduct=0
Important The product ID is typically set to zero for Microsoft Business Solutions - Great Plains, but the product ID can be the product ID of any product in the Dynamics.set file.
  1. Start Microsoft Dynamics GP or Microsoft Business Solutions - Great Plains, and then log on to the application.
  2. In the application, move to a location just before the section of code that you want to analyze.
  3. To analyze the code, follow these steps:
    1. Click Debug, click Log Scripts, and then specify a path for the Script.log file.
    2. Click Debug, and then click Profile Scripts.
    3. Click Debug, and then click Clear Profile.
  4. Perform the action that you want to analyze.
  5. To stop the analysis, follow these steps:
    1. Click Debug, and then click Log Scripts.
    2. Click Debug, click Save Profile, and then specify a path for the Profile.txt file.
    3. Click Debug, and then click Profile Scripts.
  6. Locate the Script.log file and the Profile.txt file, and then send these files to a developer or to the support team for analysis.

Evaluating the logs
To identify the scripts that are experiencing slow performance, open the Profile.txt file by using Notepad. (Make sure that Word Wrap on the Format menu is not selected.) The scripts that have the highest values in the Count column and in the +Children column may be the scripts that are experiencing slow performance. To identify the child scripts and the parent scripts of a particular script, search for the script in the Script.log file. Child scripts are shown under the script. The child scripts are indented. The parent scripts are higher in the hierarchy than the child scripts.

You can also use the Profile.txt file to identify the tables that Dexterity used while the Dexterity Script Debugger was running. However, tables that were accessed by stored procedures are not shown in these statistics. Additionally, the internal workings of a stored procedure are not captured by the Dexterity Script Debugger. To capture this information, you must run a trace in SQL Server.

Keywords: dexterity, script, debugger, trace, bugs, performance