As of now - Great Plains Dynamics/eEnterprise is transformed/renamed into Microsoft Great Plains and Microsoft Business Solutions is in process of merging all its accounting applications: Great Plains, Solomon, Navision and Axapta into somewhat granular: Microsoft Financials, Microsoft HR, Microsoft Distributions, Microsoft Project Accounting, etc. So the original design of Great Plains should be deemphasized. But even now - Great Plains is written on the programming language and technology, created in early 1990-th, named Great Plains Dexterity. And the graphical interface looks very user friendly and nice - these are all Dexterity forms and screens.

The original architect of Dexterity, Tim Brookins, pursued several goals, the main are these:

1. Engine, supporting graphical interface, which is computer platform independent - if you remember those days - the main competition was between Macintosh and Microsoft Windows. Mac was graphical and very popular, but Windows, backed by IBM cloning/platform openness was very dangerous competitor. The new engine was targeted to work on both: Mac and Windows. On the other hand - nobody could look at the future far enough to be sure that other competitors from both Hardware and Operating Systems sides not going to take over. This is why the graphical platform independent engine was required for the new type - Graphical accounting/ERP system: Great Plains Dynamics.

2. Database platform independence - initially Great Plains used Ctree (available for both PC and Mac) and Btrieve, later on with Microsoft SQL Server 6.5 Great Plains relatively easy introduced it as a new alternative: Dynamics C/S+ on SQL Server. Again - nobody could guarantee which DB will be a winner. Technically Dexterity could easy provide DB switch. Unfortunately - the necessity to support "cheap" databases, such as ctree forced Dexterity architect to use cursors or loops instead of providing aggregation, available on all SQL blends.

To resolve these goals, and following popular those days believe that C programming language is platform independent, C was chosen as the low level language to write dexterity itself.

This was the story, now to the practical side. You

1. Native Dexterity Cursors. Dexterity was designed as platform independent programming language and so if you want your code to be operable on all currently supported databases – you use Dexterity ranges and loops to manipulate the records

2. Great Plains Dexterity with SQL Stored Procs Nowadays, most of Great Plains installations are moved to SQL Server – so you can use Dexterity for custom forms drawing only and make the buttons run SQL stored procedures.

3. COM Objects calls. Beginning with version 7.0 Dexterity supports COM objects – you register them as libraries in Dexterity. Refer the manual. This technique allows you to call such nice things as web services across the internet.

4. Dexterity Forms – if you like VBA and are comfortable to do all the business logic in VBA – you can use Dexterity as new forms creator/editor. This is OK – but you have to purchase VBA/Modifier and Customization Site Enabler from MBS.

Some restrictions. Great Plains is actually integration of multiple dictionaries: DYNAMICS.DIC, ADVSECUR.DIC, EXP1493.DIC, etc. In your Dexterity customization you can deal with one dictionary – DYNAMICS.DIC. If you need cross dictionaries customization – consider using SQL Stored Procs for crossing dictionary borders and pulling data/making changes in the other dictionary.

Happy customizing! if you want us to do the job - give us a call 1-866-528-0577! help@albaspectrum.com

Andrew Karasev is Chief Technology Officer in Alba Spectrum Technologies – USA nationwide Great Plains, Microsoft CRM customization company, based in Chicago, California, Texas, Arizona, Florida, Georgia, New York and having locations in multiple states and internationally (www.albaspectrum.com), he is Dexterity, SQL, C#.Net, Crystal Reports and Microsoft CRM SDK developer.

akarasev@albaspectrum.com