5 Support Debugging Tool features you should be using today: Decisions Fall 2011

November 23, 2011
The Decisions Fall 2011 virtual conference is around the corner, with Dynamics GP Day scheduled for Tuesday, December 6 2011. Please register to participate in the conference. This is a unique, virtual conference experience. No, it’s not a boring webinar and surely not the kind of place where you will be ran over by tons of people walking up in hallways and down escalators trying to get to a session room. You can do this from the comfort of your office, sofa, or even your tricked out basement office. There’s no excuse – that I can think of anyways – for not participating.

This time around, I will be presenting a topic around – what else! – the Support Debugging Tool: “5 Support Debugging Tool features you should be using today with Microsoft Dynamics GP”. What can I say, I love long session titles.

This session is strictly an end-user oriented presentation whose sole objective is to demistify the complexities of the Standard Mode options in the Support Debugging Tool. That’s right! No complex scripts, no Dexterity triggers, no XML mambo jambo… just plain simple talk on what’s available for YOU the everyday mortal who works with Microsoft Dynamics GP.

Want the advanced stuff? Meet David and I at Microsoft Convergence 2012 in Houston (more on this in another post).

The session will feature 5 simple demoes that will, once and for all, convince you of installing the tool in your environment.

I will also be a panelist at the Microsoft Dynamics GP MVP Roundtable with my compadres, Frank Hamelly, Jivtesh Singh, and Mark Polino. You get to ask us anything Microsoft Dynamics GP and have some fun in the process. Register now!

Until next post!

Mariano Gomez, MVP
IntellPartners, LLC


Decisions Fall 2011 Virtual Conference registrations now open

October 18, 2011

Well folks, as I mentioned before, this year-end is going to be a bit busy on my calendar. In addition to my Las Vegas adventure with the GPUG folks, I am speaking at the MSDynamicsWorld Decisions Fall 2011 virtual conference. This time, I am adding a 30-minute, fast paced Support Debugging Tool session.

Please come join my session Five Support Debugging Tool Features You Should be Using Today with Microsoft Dynamics GP. That’s it! You just need to sit in for 30 minutes and as a result you will gain a good understanding of the key end-user and administrative functions available in the tool.

Also join me in a live Microsoft Dynamics GP MVP Panel featuring my fellow MVPs, Frank Hamelly, Jivtesh Singh, and Mark Polino. Seriously, in what circus do you get to ask four clowns a question and get an intelligent response? Well, now is your chance. We promise to make this entertaining and fun in a relaxed setting.

Register now!

Until next post!

Mariano Gomez, MVP
IntellPartners, LLC

Automating the start and stop of Microsoft Dynamics GP logs with the Support Debugging Tool – Part 2

July 28, 2011

Yesterday, we tackled the first part of this Support Debugging Tool project, showing how to implement the logging trigger portion. To recap, the application logging files (DEXSQL.LOG and Dexterity Script Log) will begin to record when the Hold checkbox on the Vendor Maintenance window is marked. However, registering the logging trigger will only occur when the Vendor Maintenance form is opened, and unregister, when the Vendor Maintenance form is closed. This will provide an effective set of actions to be recorded as opposed to logging every single action that occurs within the application.

Now that we have implemented the logging portion, we need the two non-logging triggers: the trigger that will start the logging trigger, and the one that will stop it.

The Start Trigger

We will start by setting up the non-logging trigger that will activate the VEND_HOLD_CHG logging trigger (which in turn will begin logging only when the Hold checkbox is marked). We will want to attach this trigger to the Vendor Maintenance form PRE script. We want the logging trigger to register once the Microsoft Dynamics GP code has run, hence we will startup the logging trigger after the original event. Unlike the logging trigger, this trigger start automatically upon the user launching and login into Microsoft Dynamics GP.

ST_VENDHOLD_LOG non-logging trigger – Resource tab

We will move to the Script tab and use a Helper function to assist with adding the code that will start up the logging trigger. By clicking on the Helper button, the Insert Helper Function window displays, from where we can choose the Start an Automatic Mode Trigger ID option in the drop-down list.

Insert Helper Function window

Then we can move to select the logging trigger ID, VEND_HOLD_CHG created previously.

Again, the Support Debugging Tool does most of the sanScript coding needed for this purpose by calling the built-in API procedure MBS_Trigger_Start to start up our VEND_HOLD_CHG trigger. Very convenient!

ST_VENDHOLD_LOG non-logging trigger – Script tab

Next we need to setup the non-logging trigger to disable the logging trigger.

The Stop Trigger

For this case, and instead of trying to replicate all these setups, we can take advantage of the Duplicate button of the Automatic Debugger Mode setup window to create a copy of the start up trigger.

Duplicate Button

Finally, we adjust the non-logging trigger to fire after the Vendor Maintenance form post script has executed, and change its script to call the MBS_Trigger_Stop Support Debugging Tool API function to un-register the VEND_HOLD_CHG trigger, effectively stopping all logging.

EN_VENDHOLD_LOG non-logging trigger

Now is time to turn on our non-logging triggers (which are set to start up automatically on login in into the Microsoft Dynamics GP application).

Turning on non-logging automatic start only triggers

A look the Automatic Debugger Mode status window shows our non-logging triggers waiting for the Vendor Maintenance window to open.

Automatic Debugger Mode Status window

If we open the Vendor Maintenance window we will see our trigger VEND_HOLD_CHG trigger is automatically registered (along with a secondary trigger that captures the original value of the field prior to being selected so it can be restored if needed). The Support Debugging Tool main window will change the color and prompt of the Automatic Debugger Mode button. When the Hold checkbox is marked, the logging trigger activates the logs and displays the desktop alert.

And all of this occurred without the end-user’s intervention. In addition, the DEXSQL.LOG and Script Log files will only contain all events that occurred while the window was opened and records were manipulated. Once the Vendor Maintenance window was closed, the logs were suspended.

I have attached the configuration file to be imported with the Support Debugging Tool’s Configuration Export/Import window. Once you import the XML file just activate the non-logging triggers as indicated above and you should be good to go.

Vendor Hold triggers – VEND_HOLD.zip

Discover the power of the Support Debugging Tool.

Until next post!

Mariano Gomez, MVP
IntellPartners, LLC

Automating the start and stop of Microsoft Dynamics GP logs with the Support Debugging Tool – Part 1

July 27, 2011

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.

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

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.

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!

Mariano Gomez, MVP
IntellPartners, LLC

Defaulting "Include Totals and Deposits" in Sales Transfer Entry with the Support Debugging Tool

July 26, 2011

More times than I care to count I have been called in to fix records left behind because the Include Totals and Deposits option was not marked when transferring a sales document from an existing order to an invoice. The problem is, it is so easy to forget to mark that box if you are doing this for hundreds of transactions fractured in multiple batches, especially at the end of the week when invoices need to be submitted to customers, prior to the FedEx truck arriving at 4:00 PM.

Sales Transfer Documents window

While this “fix” has been provided as a Modifier with VBA project before, I thought, why not really prop this up a bit with a Support Debugging Tool non-logging trigger and take advantage of the Automatic Debugger Mode functionality? Well, I have done just that!

The first thing we need to do is setup the trigger itself. In this case, we want to select a Focus Event trigger that will fire exactly on a field change condition. The field in question is the ‘(L) Order To Invoice CB’ checkbox field. You can use the lookup button next to the Form Name field on the Resource tab to open the Support Debugging Tool’s Resource Explorer window and locate the field and select it.

Trigger Setup

Since this will be a non-logging trigger, we will want to check the Do not activate Logging Mode option on the window. And to make sure the trigger always starts up with Microsoft Dynamics GP, we will want to check the Start Trigger Automatically on Login option as well.

Second, we can choose to have the Support Debugging Tool perform certain actions when the event fires – the event being when the checkbox is marked. If you happen to be running build 15 of the SDT, you can have a message display as a desktop alert on the lower right corner of your screen, similar to when you receive a Microsoft Outlook message.

For the purpose of this trigger, we will not take any actions when the trigger fires.

Third, we must add the processing script. The Support Debugging Tool does a really good job at providing a helper to build upon. So all we need to do is add the little bit to process the Include Totals and Deposits checkbox field, after the Transfer to Invoice checkbox has been marked. This is the final script:

Trigger processing script

Finally, since this is a non-logging trigger, the Options tab will show all logging options disabled. However, you can still choose a date range for this trigger to take effect.

Options tab

Since the goal is to have this trigger available at all times, there’s no need to add a start and end date. It’s now time to save the trigger and enable it.

We can choose to turn on our Non Logging Automatic Start Only triggers. Since our SOP_XFER trigger has been marked as a non-logging automatic trigger we should be able to see it in the Automatic Debugger Mode Status window.

Automatic Debugger Mode Status window

This is really all there is to it! The trigger should now cause the Include Totals and Deposits checkbox to activate automatically when we choose the Orders to Invoices checkbox.

I have attached the configuration file to be imported with the Support Debugging Tool’s Configuration Export/Import window. Once you import the XML file just activate your trigger as indicated above and you should be good to go. No more forgetting to mark Include Totals and Deposits when transferring orders to invoices.

Include Totals and Deposits trigger – SOP_XFER.zip

The Support Debugging Tool’s non-logging triggers functionality is a very powerful way to deploy simple scripts that can take care of every day headaches. All you need is a bit of creativity and the tool itself – see David Musgrave’s article Support Debugging Tool Build 15 released for more on the latest Support Debugging Tool build.

Until next post!

Mariano Gomez, MVP
IntellPartners, LLC

Support Debugging Tool Build 15 now released

June 30, 2011

These are exciting times… the Support Debugging Tool Build 15 has been released! If you attended our session, CSGP014-R2 Administering Microsoft Dynamics GP Like a Pro with the Support Debugging Tool during Convergence Atlanta 2011, you may recall that the features David Musgrave (author of the Support Debugging Tool) and I presented were all part of the Build 15 beta release at the time. Since then, the Support Debugging Tool has been propped up with a number of enhancements and bug fixes that make the wait while worth.

Support Debugging Tool Build 15 – UI Facelift

Take a look at David Musgrave’s release article, Support Debugging Tool Build 15 released, for a complete list of fixes, enhancements, performance improvements, usability and  features included in the new build.

Build 15 is only available for Microsoft Dynamics GP 10.0, Microsoft Dynamics GP 2010, and Microsoft Dynamics GP 2010 R2. You can download Build 15 at:

Support Debugging Tool for Microsoft Dynamics GP 10.0 Secure Link
Support Debugging Tool for Microsoft Dynamics GP 2010 (v11.0) Secure Link

Also, I will be writing in the coming days on some of the features I personally suggested and that are now a part of the Support Debugging Tool.

Until next post!

Mariano Gomez, MVP
IntellPartners, LLC

>Resetting Security Roles and Task with the Support Debugging Tool

April 18, 2011

>This is my first after Convergence post and I have to say, I came away with enough questions from attendees to fill the blog for the remainder of the year. One such questions came from someone attending the interactive discussion session on security, IDGP04-R2 Tips and Tricks for Maintaining Security in Microsoft Dynamics GP – see Microsoft Dynamics Convergence Atlanta 2011: Day 4 Morning Closing Session (Cont.) for more on what transpired that day.

The individual in question wanted to know if there is a way or method to “reset” all Microsoft Dynamics GP security roles and tasks to the out-of-the-box defaults once these had been changed. After thinking about it for a bit, there is effectively a way using the Support Debugging Tool.

Step 1 – Export the security tables from a brand new installation of Microsoft Dynamics GP
In a brand new installation of Microsoft Dynamics GP, install and use the Support Debugging Tool’s XML Table Export feature to create a SECURITY profile ID, including all the security tables as shown below.

XML Table Export – SECURITY profile ID

 Step 2 – Optional: Clear the destination system’s security tables

You can then create a script using the Support Debugging Tool’s SQL Execute that will clear all the security tables in your destination system, as shown below.

SQL Execute – Clears security tables

By saving the script ID we can reuse the code as many times as needed or for future resets. Note also, that I have used the Dexterity table notation in the DELETE statement as I already had the names in the XML Table Export window.

Step 3 – Import the records exported in step 1 into the destination system

Finally, we can use Support Debugging Tool’s XML Table Import feature to reset security and reload the defaults from the XML file exported in step 1. Note that I have marked the Overwrite Table Contents option, which would render step 2 not necessary. However, having step 2 reduces your chances of forgetting to select this checkmark.

XML Table Import

I have attached the SECURITY profile ID and the RESET_SECURITY script ID at the bottom of this post. I am also including the exported security tables XML files with the default security tasks, roles and assignments. Remember that you can choose a reduce set of data to export or remove tables that you may not want to import. It all depends what level of granularity you are trying to achieve.


DebuggerInfo.zip – contains SECURITY profile ID, RESET_SECURITY script ID, and default security roles, tasks and operations for Microsoft Dynamics GP 2010.

Until next post!

Mariano Gomez, MVP
IntellPartners, LLC