Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Using the Debugger to trace Bugs and performance issues

Dexterity Techniques

Using the Debugger to trace Bugs and performance issues

by  winthropdc  Posted    (Edited  )
Using the Debugger to trace Bugs and performance issues FAQ
===========================================================

When trying to identify the cause of a bug or understand why some functions might have slow performance, support teams normally request a DEXSQL.LOG to be generated. The DEXSQL.LOG shows all the communication between the Application and the SQL Server. However, it does not show what internal processing is occuring in the application or access to non SQL based tables, such as local temporary tables.

The Dexterity Debugger has two methods of tracing what is happening in the code:

1) The Script Log which shows all scripts called in their hierarchy and their parameters.

2) The Script Profile which lists all the scripts called and tables references, how many times and how many seconds were taken.


The steps below show how to enable the Dexterity Script Debugger in a live runtime environment and how to generate the Script Log and Script Profile:

a) Edit the DEX.INI file and add the following lines into the [General] Section

ScriptDebugger=TRUE
ScriptDebuggerProduct=0

The Product ID is normally 0 for Great Plains, but can be the product ID of any product in the DYNAMICS.SET launch file.

b) Launch Great Plains and log in. Navigate in the application to a point just prior to the section of code you wish to analyse.

c) There should be a Debug menu on the right hand side of the menu bar, use the following steps to start the analysis:

i) Click Debug, click Log Scripts and specify a path for the Script.log file.
ii) Click Debug then click Profile Scripts to activate profiling.
iii) Click Debug then click Clear Profile to reset the profile at the start.

d) Perform the action you wish to analyse.

e) Stop the analysis with the following steps:


i) Click Debug then click Log Scripts to stop the logging.
ii) Click Debug, click Save Profile and specify a path for the Profile.txt file.
iii) Click Debug then click Profile Scripts to de-activate profiling.

f) Locate the Script.log and Profile.txt files and forward them to a developer or the support team for analysis.


To see where the time is being spent for performance issues, open the Profile.txt file with Notepad and make sure Word Wrap (under the Format menu) is off. Scripts of interest are those with the highest values in the Count and +Children columns. To identify the children and parent of a particular script, search for it in the script.log. Children will be shown below the script and indented. The parent will be the first script above with one less level of indentation.

The Profile.txt file can also be used to identify the tables used by Dexterity while the logging was active. Tables accessed by stored procedures or pass through SQL will not be shown in these statistics.

Note that the internal workings of a stored procedure or pass through SQL are not captured by the Dexterity Debugger and would need a SQL Trace to see exactly what is happening.


David Musgrave [MSFT]
Senior Development Consultant
MBS Services - Asia Pacific

Microsoft Business Solutions
http://www.microsoft.com/BusinessSolutions

Any views contained within are my personal views and
not necessarily Microsoft Business Solutions policy.
This posting is provided "AS IS" with no warranties,
and confers no rights.
Register to rate this FAQ  : BAD 1 2 3 4 5 6 7 8 9 10 GOOD
Please Note: 1 is Bad, 10 is Good :-)

Part and Inventory Search

Back
Top