First Look at Support Debugging Tool for Microsoft Dynamics GP

August 29, 2008

I have been beta testing the Support Debugging Tool (SDT) for Dynamics GP for a couple of weeks. My first impressions orbited around admiration for the author, none other than David Musgrave, followed by the natural curiosity on the powerful features provided by the tool itself.

The product is compatible with releases 8.0, 9.0, and 10.0. SDT was first introduced during the Microsoft Dynamics GP Technical Airlift , in May of 2008 with great reception from the attending partner community. Unlike the Script Debugger Tool (activated by including ScriptDebugger = TRUE in the Dex.ini file) Support Debugging Tool is geared towards the consultant and end-user to assist in troubleshooting application issues without the complexities involved in understanding the application development process.

Modes of Operation

The Support Debugging Tool offers two modes of operation: Standard Mode and Advanced Mode.

The Standard Mode is a read-only mode which helps with application logging and providing resource and security information.

The Advanced Mode adds triggering and scripting capabilities, data export and import and dictionary control. The Advanced Mode is activated by controlling settings in the Dex.ini file — all from the interface and without leaving Dynamics GP! This mode of operation has been conceived with the systems administrator and partner support staff in mind since it delivers powerful options including the ability to visualize table data and change Dynamics GP’s behavior by enabling and disabling features.

This is what I call Support Debugging Tool on steroids and definitely not made for the end-user. Support Debugging Tool was created with one thing in mind: absolute traceability of the Dynamics GP application events and full control of the application settings. At the heart of its existence is the Automatic Debugger Mode.

The Automatic Debugger Mode uses the logging options and Dexterity triggers to log application and SQL activity up to a specific event and error condition. You read correctly! Now you have the ability to trace scripts up to the point of a condition leading to a breakdown in the application logic, which results in an error in the data being written in the tables. However, the use of the Automatic Debugger Mode requires administrative rights and the setup of Dexterity triggers for each event being monitored. For example, if the error condition involves data in a table, the trigger event used could be when the table in question is saved. If the error condition involves a field on a window, the trigger event could be when the field in question is changed. After the trigger event is selected, a conditional script is written using Dexterity sanScript to check whether the error condition has actually occurred. Scripts written for this purpose will require the assistance of an experienced Dexterity developer.

While this is the primary goal, I was able to setup a trigger on the Customer Name field under the Customer Maintenance window to convert the field value to upper case after the user tabs off the field. Among other things, the Support Debugging Tool can assist partners and customers (through their partners) with:

· Quickly and simply turn on all logging and profiling capabilities without restarting the application. This can be useful when looking at performance problems.

· Finding details about dictionary resources loaded in their customer’s environment.

· Identifying resources (forms, reports and tables) causing security access issues.

· Enabling and disabling third party products or change the order of the products in the launch file.

· Exporting data from and importing to any table.

· Exporting triggers and configuration options that can be imported and activated in customers production environments.

· Running SQL or Dexterity scripts without needing Dexterity or SQL Server administration tools installed.

Support Debugging Tool will be available via PartnerSource only. Customer wishing to obtain the tool may request a copy from their partners. Support Debugging Tool will be supported on the Microsoft Dynamics GP Developer’s newsgroup. Messages posted there will need to be prefixed by “SDT: ” which will prompt the Tools team to respond.

Support Debugging Tool Resources

For a 41-minutes-and-47-seconds action packed demonstration of Support Debugging Tool features follow this link on Microsoft Partner Program Training center (at least Registered Partner level required). Once the Office Live Meeting presentation is downloaded, you can fast-forward to slide 21 where David takes over. You can also read more about Support Debugging Tool on David’s Developing for Dynamics GP blog site or can always refer back to my first article on the tool as well.

Until next post!

MG.-
Mariano Gomez, MIS, MVP, MCP, PMP
Maximum Global Business, LLC

Dexterity Bug: ScriptDebugger Dex.ini Setting Causes Dynamics GP Menu to Behave Erraticaly

August 29, 2008


For those of us who work in development environments, the Script Debugger Tool is essential to unit test and follow code released into QA — note I say QA, the Script Debugger was not conceived to be used in Production environments — perhaps a reason why this issue has not been fixed by Microsoft yet!

When the Script Debugger Tool is activated — by adding ScriptDebugger = TRUE in the Dex.ini file — a Debug menu is added to the Dynamics GP menu bar. I have noticed the menu reorganized itself randomly when switching between Dynamics GP and Modifier or even when closing the application and reopening it.

The behavior is consistent even when the Toolbar has been locked via the Navigation menu options. This has been identified as a bug in the Dexterity runtime engine, but has certainly not made it into Microsoft list of fix priorities.

Until next post!

MG.-
Mariano Gomez, MIS, MVP, MCP, PMP
Maximum Global Business, LLC.
http://www.maximumglobalbusiness.com/


Dexterity Training in Orlando (Oct 20 – Oct 24) featuring Leslie Vail, MVP

August 27, 2008

Ever asked yourself why Dexterity developers are so hard to find and in such a high demand? Do you have experience programming in other development environments and still looking to bring another environment under your belt? Sweat it no more! Integrated Business Group (IBG) in Orlando is featuring Leslie Vail, fellow MVP and by far one of the best Microsoft Dynamics GP Certified Trainers. The training will take place in Orlando, Florida from October 20 to October 24, and will be providing the basic foundations any Dexterity programmer must have.

Integrated Business Group will consider running the Dexterity II training, pending the outcome of this session. This course (previously known as the Dexterity Advanced Integration Techniques) is a 5 day course featuring integration techniques with the Microsoft Dynamics GP application.

For more information, contact the training coordinator, Roxanna Alvarez at ralvarez@ibgnet.com or at her direct line +1 (407) 965-9299.

Until next post!

MG.-
Mariano Gomez, MIS, MVP, MCP, PMP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/


David Musgrave on Automating the Distribution of Customizations

August 27, 2008

David has published two very detailed articles regarding the automatic deployment of customizations. Article I explores the different deployment scenarios for dictionaries and application files with pros and cons for each configuration, while Article II explores the automation of the deployment of customizations. However, the articles do not cover complex deployments in Citrix and Terminal Server environments and are not recommended for upgrades or deployment of new clients.

Drop a comment to David and let him know how (or how not) you can use his suggestions.

Until next post!

MG.-
Mariano Gomez, MIS, MVP, MCP, PMP
Maximum Global Business, LLC.
http://www.maximumglobalbusiness.com


Microsoft Dynamics GP and SQL Server Collations

August 19, 2008

I have seen this question posted in multiple shapes and forms, but could well be rounded up as follows: “I installed Microsoft SQL Server with an Arabic_BIN collation. In addition, I installed Microsoft Dynamics GP on my server and a few clients. All my clients can access the system with no problems. However, I have this one user who ‘accidentally’ switched his/her Windows locale to English (United States) and is getting all sorts of errors when accessing the system or trying to enter transactions or master records.”

This is not at all uncommon, but to put an end to the myths sorrounding this issue it is necessary to understand how collations work in both Microsoft Windows and Microsoft SQL Server.

Windows Collations

Windows collations are collations defined for SQL Server to support Windows locales. By specifying a Windows collation for SQL Server, the instance of SQL Server uses the same code pages and sorting and comparison rules as the Microsoft Dynamics GP client that is running on a computer for which you have specified the associated Windows locale. For example, the French Windows collation for SQL Server matches the collation attributes of the French locale for Windows.

There are more Windows locales than there are SQL Server Windows collations. The names of Windows locales are based on a language and territory, for example, French (Canada). However, several languages share common alphabets and rules for sorting and comparing characters. For example, 33 Windows locales, including all the Portuguese and English Windows locales, use the Latin1 code page (1252) and follow a common set of rules for sorting and comparing characters.

The SQL Server Windows collation, based on the Latin1_General code page and sorting rules, supports all 33 of these Windows locales. Also, Windows locales specify attributes that are not covered by SQL Server Windows collations such as currency, date, and time formats. Because countries and regions such as Great Britain and the United States have different currency, date, and time formats, they require different Windows collations. They do not require different SQL Server collations, because they have the same alphabet and rules for sorting and comparing characters.

In SQL Server, Windows collations are combined with a series of suffixes to additionally define sorting and comparison rules based on case, accent, kana, and width sensitivity.

SQL Server Collations

SQL collations are a compatibility option to match the attributes of common combinations of code-page number and sort orders that have been specified in earlier versions of SQL Server. Many of these collations support suffixes for case, accent, kana, and width sensitivity, but not always.

In SQL Server 2005, you should primarily use Windows collations. This is particularly true if you have a mix of Unicode and non-Unicode columns in your database. Windows collations actually apply Unicode-based sorting rules to both Unicode and non-Unicode data. This means that SQL Server internally converts non-Unicode data to Unicode to perform comparison operations. This provides consistency across data types in SQL Server and also provides developers with the ability to sort strings in their applications that use the same rules that SQL Server uses.

SQL collations, on the other hand, apply non-Unicode sorting rules to non-Unicode data, and Unicode sorting rules to Unicode data, by using a corresponding Windows collation for the Unicode data. This difference can cause inconsistent results for comparisons of the same characters. Therefore, if you have a mix of Unicode and non-Unicode columns in your database, they should all be defined by using Windows collations so that the same sorting rules are used across Unicode and non-Unicode data.

You should use SQL collations only to maintain compatibility with existing instances of earlier versions of SQL Server or to maintain compatibility in applications that were developed by using SQL collations in earlier versions of SQL Server.

There can be differences in performance between Windows collations and SQL collations, but that would be topic for another blog. For now, if you need to change your DYNAMICS or company databases collation, make sure to check back in the future where I will discuss a few methods to accomplish this.

Until next post!

MG.-
Mariano Gomez, MIS, MVP, MCP, PMP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/


Know thy Common Table Operations with Dexterity – Part I

August 19, 2008
The first thing most of us learn from working with any relational database and software development language is how to perform common table operations (create, read, update, and delete). It is no different with Microsoft Dexterity. If you’ve read through David Musgrave’s recommendations for getting started with Dexterity, then the next logical question is how to begin working programmatically with tables. This post will not focus on the in and outs of the table creation process, however, a brief explanation of some concepts that is required to move forward.

Creating tables

When you create a table in Dexterity, you’ll use or define several elements required for the table to store and access information properly, such as fields, keys and table relationships. Before you create tables, be sure you have previously defined all the fields that you’ll be using to store information in the table.

If you are creating applications that integrate with Microsoft Dynamics GP, be aware that Microsoft Dynamics GP table structures CANNOT be modified. Because you can do so, does not mean your should. Any additional information (say for example Customer Hotel Preferences) must be stored in extended tables with the same primary key used by the original Dynamics GP table, which in turn will allow you to setup table relationships. Maintaining GP tables intact will facilitate applying service packs and performing upgrades to your Dynamics GP application.

You will use the Table Definition window to create a table.

I always recommend a careful review of the Dexterity Programmer’s Guide Volume I manual provided with Microsoft Dexterity which explains the table creation process in detail.

Understanding Table Buffers

Each time a table is attached to a form, a table buffer is automatically created for that table. If you attach a table to more than one form, each form will have its own table buffer for that table. The following example shows all the tables attached to the RM_Customer_Maintenance form. When the form is opened in the application, each table buffer is loaded into memory ready to receive a record.

A table buffer usually contains one record which comes from either windows that are part of the form or from the table, depending on whether the record is being read from the table or being stored from the window to the table.

It is perhaps a good time to check David’s latest article on discarding changes from transaction windows as it is very intertwined with the implementation of forms, windows, and table buffers, along with some referential integrity issues that may suscitate when saving information to multiple tables at once.

Common Table Operations

Now that you understand some of the concepts let’s move on to common table operations. Typically, as with other development environments, data in tables is a direct result of users’ interaction with the application windows. Data is constantly transported back and forth from windows to tables and from tables to windows where users can perform subsequent operations on the data such as create new records, retrieve existing records, perform updates, and delete records. In Dexterity, this transport of data is accomplished via scripting — SanScript in particular.

The SanScript language is equipped with four powerful statements that are the basis for table operations:

get statement
change table statement
save table statement
remove table statement

My next installment will describe in detail how these statements work and the do’s and don’ts when working with them.

Until next post!

MG.-
Mariano Gomez, MIS, MVP, MCP, PMP
Maximum Global Business, LLC.
http://www.maximumglobalbusiness.com/


All About Named Printers on Terminal Server

August 15, 2008

David Musgrave has published a new blog entry on everything you ever wanted to know about installing Named Printers on a Terminal Server environment. As the original developer of Named Printers, Dave certainly is an authority on the issue and demonstrates it in his latest entry. He makes some bold annotations to help users setup Named Printers effectively and points to some valuable articles he has contributed or in many occasions written.

Stop by Dave’s blog site, read up, and let him know what you think.

Until next post!

MG.-
Mariano Gomez, MIS, MVP, MCP, PMP
Maximum Global Business, LLC
http://maximumglobalbusiness.com/