Free Articles, Free Web Content, Reprint Articles
Saturday, September 21, 2019
Free Articles, Free Web Content, Reprint ArticlesRegisterAll CategoriesTop AuthorsSubmit Article (Article Submission)ContactSubscribe Free Articles, Free Web Content, Reprint Articles

Great Plains Customization: Dexterity code upgrade overview for Consultant

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. 

These programming parts are written in Dex Sanscript programming language.  Sanscript is sort of proprietary scripting language, 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 itComputer Technology Articles, as it is virtually impossible to debug such code samples

Source: Free Articles from


Andrew Karasev, Alba Spectrum 1-866-528-0577, 1-630-961-5918, serving Great Plains USA and Canada nationwide.  Local service in Chicago, Houston, Dallas, San Diego.  Please visit our information portal Pegas Planet: .  If you need custom programming for GP, we are happy to help you with Dexterity, eConnect, VBA/Modifier, SQL Stored Procedures, Crystal Reports.  We also provide instant support to new and existing clients via web sessions for the customers in CA, IL, WI, NY, FL, IN, MI, TX, GA, NE, NM, AI, NC, SC, OR, WA, DC, DE, PA, VI, AZ, LA

Home Repair
Home Business
Self Help

Page loaded in 0.147 seconds