Automating the start and stop of Microsoft Dynamics GP logs with the Support Debugging Tool - Part 1
If you haven't noticed, it is - unofficially, of course - Support Debugging Tool week. With the fairly recent release of build 15 and a revision of that build, the tool has just gotten better with heaps of new features and improvements over existing ones! And I am exploring some really cool stuff that can be done with the product. Yesterday I showed how you can use the Automatic Debugger Mode's non-logging trigger capabilities to Default "Include Totals and Deposits" in the Sales Transfer Entry window
Today, I will touch on the topic of Automatic Debugger Mode and non-logging triggers again. However, this time I will show how you can use non-logging triggers in combination with logging triggers to capture vital application logs upon the occurrence of some Microsoft Dynamics GP application event without user intervention.
This may sound a little esoteric, but the concept is simple. For this example we will use the Vendor Maintenance window, a very familiar window to most of you who interact with Microsoft Dynamics GP on a daily basis.
For this example, we will register two non-logging triggers on the Vendor Maintenance form: the first non-logging trigger will start up a logging trigger that initiate application events logging - DEXSQL.LOG and Dexterity Script Log for this example - when the Hold checkbox is activated. The second non-logging trigger will stop the logging trigger upon closing the Vendor Maintenance form.
Think of the advantages of this for a second... imagine a user who has been experiencing a random issue for quite some time in a window and the data being processed in that window. It would be fantastic if you could turn on and turn off Microsoft Dynamics GP logs upon certain event (or events) happening on that window without the user having to be aware or have the presence of mind to do this himself/herself. This certainly would make the process of troubleshooting quite simple, less intrusive, and more precise!
So let's take a look at what is required:
1. A logging trigger that activates our DEXSQL.LOG and Dexterity Script Log when the hold checbox is marked.
2. A non-logging trigger that will register the above logging trigger when the Vendor Maintenance form is opened.
3. A non-logging trigger that will un-register the logging trigger in number 1 when the Vendor Maintenance form is closed.
The Logging Trigger
We will start by setting up the logging trigger that will activate only when the Hold checkbox is marked. The trigger type in this case is a Focus Event and will only fire when the field changes, that is, when is marked - conceivably, you could add code that deals with the event of unmarking the checkbox. We want any action to begin once the Microsoft Dynamics GP code has run on that field, hence we will initiate our logs after the original event. Note also, this trigger will not start automatically upon the user launching and login into Microsoft Dynamics GP, since we only want this to happen when the Vendor Maintenance form is opened - and stop when it is closed.
On the Actions tab, we will just send a desktop alert to the end user by choosing the respective option.
The beauty of the Support Debugging Tool is, you really need little in the form of Dexterity development knowledge and probably just an understanding of basic programmatic constructs to follow along and complement the helper functions. See, while you were fiddling with the setup options for the trigger in the Resource tab, the Support Debugging Tool was putting together some code for you based on your selections.
Since we want the logs to be captured when the Hold checkbox is marked then the helper function seems just adequate. This means, no need to really have to add more code - unless, of course, there's something else you would like to achieve beyond what's already given in the helper code. Remember, the code is Dexterity sanScript code.
Finally, for this logging trigger, we want to, well, log something. For that we go to the Options tab.
In this tab, we will want to choose the DEXSQL.LOG and the Dexterity Script Log. If you suspect performance issues, you can activate the Dexterity Script Profiler - see How to read a Dexterity Script Profile to solve Performance Issues over at Developing for Dynamics GP for more information on this.
That's it! This easy! Our logging trigger is ready and now we will just need the non-logging triggers to start and stop it - in Dexterity parlance, register and unregister it.
Tomorrow, I will walk you through setting up the non-logging triggers that will start up this one and show some more cool helper functions. You will also have links to download the configuration files for this SDT project. For now, go and grab the Support Debugging Tool if you haven't done so yet.
Until next post!
MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/
Today, I will touch on the topic of Automatic Debugger Mode and non-logging triggers again. However, this time I will show how you can use non-logging triggers in combination with logging triggers to capture vital application logs upon the occurrence of some Microsoft Dynamics GP application event without user intervention.
This may sound a little esoteric, but the concept is simple. For this example we will use the Vendor Maintenance window, a very familiar window to most of you who interact with Microsoft Dynamics GP on a daily basis.
 |
| Vendor Maintenance |
For this example, we will register two non-logging triggers on the Vendor Maintenance form: the first non-logging trigger will start up a logging trigger that initiate application events logging - DEXSQL.LOG and Dexterity Script Log for this example - when the Hold checkbox is activated. The second non-logging trigger will stop the logging trigger upon closing the Vendor Maintenance form.
Think of the advantages of this for a second... imagine a user who has been experiencing a random issue for quite some time in a window and the data being processed in that window. It would be fantastic if you could turn on and turn off Microsoft Dynamics GP logs upon certain event (or events) happening on that window without the user having to be aware or have the presence of mind to do this himself/herself. This certainly would make the process of troubleshooting quite simple, less intrusive, and more precise!
So let's take a look at what is required:
1. A logging trigger that activates our DEXSQL.LOG and Dexterity Script Log when the hold checbox is marked.
2. A non-logging trigger that will register the above logging trigger when the Vendor Maintenance form is opened.
3. A non-logging trigger that will un-register the logging trigger in number 1 when the Vendor Maintenance form is closed.
The Logging Trigger
We will start by setting up the logging trigger that will activate only when the Hold checkbox is marked. The trigger type in this case is a Focus Event and will only fire when the field changes, that is, when is marked - conceivably, you could add code that deals with the event of unmarking the checkbox. We want any action to begin once the Microsoft Dynamics GP code has run on that field, hence we will initiate our logs after the original event. Note also, this trigger will not start automatically upon the user launching and login into Microsoft Dynamics GP, since we only want this to happen when the Vendor Maintenance form is opened - and stop when it is closed.
 |
| VEND_HOLD_CHG trigger - Resource tab |
On the Actions tab, we will just send a desktop alert to the end user by choosing the respective option.
 |
| VEND_HOLD_CHG trigger - Actions tab |
 |
| VEND_HOLD_CHG trigger - Script tab |
Since we want the logs to be captured when the Hold checkbox is marked then the helper function seems just adequate. This means, no need to really have to add more code - unless, of course, there's something else you would like to achieve beyond what's already given in the helper code. Remember, the code is Dexterity sanScript code.
Finally, for this logging trigger, we want to, well, log something. For that we go to the Options tab.
 |
| VEND_HOLD_CHG logging trigger - Options tab |
In this tab, we will want to choose the DEXSQL.LOG and the Dexterity Script Log. If you suspect performance issues, you can activate the Dexterity Script Profiler - see How to read a Dexterity Script Profile to solve Performance Issues over at Developing for Dynamics GP for more information on this.
That's it! This easy! Our logging trigger is ready and now we will just need the non-logging triggers to start and stop it - in Dexterity parlance, register and unregister it.
Tomorrow, I will walk you through setting up the non-logging triggers that will start up this one and show some more cool helper functions. You will also have links to download the configuration files for this SDT project. For now, go and grab the Support Debugging Tool if you haven't done so yet.
Until next post!
MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/
Comments
Thanks for this post. Exactly what I needed to determine the cause of a generic GP Crashing issue.
Darren Woodbrey
Lead Technical Consultant
Tidestone Solutions