Dynamics GP SQL Scripting Level Data Repair   by Andrew Karasev

This mid-market Corporate ERP application is hosted in Microsoft SQL Server. However it only deploys limited batch commit and roll back SQL transaction logic. There are some questions about why it is limited and there is the diversity of the opinions. Probably one of the reasons is metadata and business logic abstraction level in Microsoft Dexterity (and its dictionaries, especially the core one Dynamics.dic). Dexterity was introduced as the abstraction level and programming shell, coded in C and allowing you to be compatible with various database platforms. Historically these platforms were Btrieve/Pervasive SQL, Ctree and Microsoft SQL Server. This abstraction from the DB platform limits programmers to go deeper in deploying such DB platform depended SQL functionality as transactions (with commit if everything is successful, otherwise rollback). When Microsoft acquired Great Plains Software and abolished non-Microsoft SQL Server DB versions (such as Pervasive SQL 2000, former Btrieve; and Ctree) Dexterity DB neutral cursors (programmed in Dexterity Sanscript) were partially replaced by SQL Stored Procedures. But these code revisions are do not have the magnitude of the whole Dexterity business logic recoding in SQL Stored Procedures, as application user interface is driven by Dex as well (large portion of Dexterity code is in fact replicated in eConnect encrypted SQL Stored Procedures, but eConnect fits rather to the integration requirements, including native technologies, such as Integration Manager, Web Services as well as SDK and libraries to be included into your MS Visual Studio C# or VB.Net project). All mentioned above should give you some apology for being vulnerable to SQL transaction failures. Let