Great Plains Customization: Dexterity code upgrade overview for Consultant

Jul 14
09:21

2008

Andrew Karasev

Andrew Karasev

  • Share this article on Facebook
  • Share this article on Twitter
  • Share this article on Linkedin

Microsoft Dynamics GP add-ons are often written in Great Plains Dexterity – with new and sometimes alternative GP forms and windows where the buttons, have scripts and forms themselves have procedures and functions.

mediaimage

These programming parts are written in Dex Sanscript programming language.  Sanscript is sort of proprietary scripting language,Great Plains Customization: Dexterity code upgrade overview for Consultant Articles typically you can get Dex programmer from GP ISV and customization partners, you should check with your Great Plains VAR for details.  When newer Dynamics GP version is released, if you plan to update to it, you have to take into consideration Dex modification upgrade requirement.  In this small publication w would like to orient you what you could expect from technical side:

1.       Alternative GP Forms.  These objects typically require special attention, and let us explain why.  Imagine, you have customized GP Sales Order Processing Entry form for GP say version 8.0.  Now, you plan to upgrade your customization to version 10.0.  In version 10.0 GP has (potentially) redesigned some functionality, added and took off several fields and buttons.  Your modification for 8.0 might of be dealing with the functionality, changed or even not present with version 10.0.  This is why Alternative GP forms are the ones, where Dexterity programmers spends large portion of upgrading code revision

2.       New GP Forms.  This is when in your Dex add-on you create the form from scratch.  New forms are typically less sensitive to the version and in majority of the cases should work fine, if you simply reapply Dex chunk with your add-on to the new version GP workstation

3.       Calling GP Stored Procedures from Dexterity code.  If you have your own custom stored procedure, which you call from Dex code, you need to review its SQL script – typically check if new version of GP has any changes in the tables, addressed in the SP.  If you call GP original stored procedure, then, you should review GP SDK to see if new version has the same set of parameters

4.       Performance improvement considerations.  If you are upgrading from really old version, especially when you move from old DB platform, such as Ctree or Pervasive SQL to MS SQL Server, then you can consider offloading some of the Dex logic, usually found in Dex cursors to custom SQL Stored Procedures, where you can benefit on the aggregation performance: Select or Insert in SQL would work a way faster than Dexterity cursor

5.       Exotic Sanscript programming examples.  In late 1990th we saw such techniques in Dex software development as inserting scripts into VBA code.  This technique allowed you in one custom add-on to address several GP dictionaries – popular example is GP Vendor Invoice and Intellisol Advanced Purchase Order Processing.  If you have something like that – we advise you to redesign it, as it is virtually impossible to debug such code samples