Microsoft Dexterity Customization future: upgrade, phase out, or walk away?

Mar 20
00:15

2007

Andrew Karasev

Andrew Karasev

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

Microsoft Dexterity or former Great Plains Dexterity was designed in earlier 1990th with assumption that C programming language will provide computer platform independence: Microsoft Windows vs. Mac or Solaris/Unix, plus database independence or at least easy switch: Ctree, Pervasive SQL/Btrieve, MS SQL Server, Oracle, DBII, etc

mediaimage

Dexterity architecture was transferred to MS Visual C++ somewhere around 1999 with some additional bug fixing work,Microsoft Dexterity Customization future: upgrade, phase out, or walk away? Articles however pretty flawless.  When Microsoft purchased Great Plains Software on the edge of XXI Century, the basis of Dexterity lost its actuality – in fact Microsoft Business Solutions actively moved toward phasing out all the other platforms, but MS SQL Server by introducing MSDE platform – free version of SQL Server, without some tools, however.  Let’s look at MS Dexterity from this angle:

  • Database Access.  Microsoft Dexterity, comparing to old Dexterity had to emphasize MS SQL Server stored procedures calls and scripts.  This meant that former Dex cursors (as being db platform independent) lost their actuality.  Now it is probably good programming tone to use SQL Stored Procedures to speed up dex scripting from the side of database manipulations
  • Dex Screens.  Still good idea to keep dex screen developing, following by eConnect object oriented logic behind.  As Microsoft is emphasizing MS Visual Studio .Net development options, here we would recommend Dex screens to be filled with eConnect logic via DLLs where you call either eConnect DLL procedures or XML web services eConnect interface
  • SQL Stored Procedures.  This approach still requires some experience with Dexterity programming: DEX_ROW_ID, DYNAMICS.DIC dex source code programming, dexterity atomic SQL stored procedures – you should be familiar with these legacy dexterity features
  • Dexterity International Aspect.  Unicode – this is real problem.  We often hear customer questions about dex supporting Unicode: Chinese, Japanese, Korean characters.  However some tools can help, Crystal reports for example – we have to express pessimistic view here
  • Extender optimism.  eOne Extender is very promising tools, if you are end customer – it allows you to forget about dex proprietary features and concentrate on GP prototyping: tables, forms, reports, plus even dex sanscript logic – if you have this under your belt