Microsoft Great Plains: Customization Upgrade & Recovery – Visual Studio VB 6.0

Jul 28
17:04

2005

Andrew Karasev

Andrew Karasev

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

Microsoft Great Plains, former Great Plains Software Dynamics, eEnterprise has very long, about 12 years customization & integration history. In earlier 1990th – the customization tool was mostly Great Plains Dexterity, later on when Great Plains was successfully moved to MS SQL Server 6.5, 7.0 and 2000 – we see more historical custom projects done in SQL stored procedures and front ends coded in VB in Visual Studio 6.0.

mediaimage

This was probably wise and natural choice in that time (around 1997-2001),Microsoft Great Plains: Customization Upgrade & Recovery – Visual Studio VB 6.0 Articles but if you consider Microsoft move to .Net platform and reshaping its own programming environments (ADO, OLE, VB, etc) – you would nowadays rather be nervous relying on VB 6.0 custom front end, calling stored procs via ADO.  Let’s consider your options:

  • Upgrade to .Net.  As natural it might sound and look, however it might not be feasible.  The reason is - .Net is the whole revolution to Windows object model (or its introduction, somewhat more revolutionary, than J2EE/EJB/Java).  Your old VB code is not object oriented in the sense of .Net and majority of technologies are now obsolete or in phase out mode
  • Move Front End to Web Application.  Or recreate simplified version as VB.Net or C#.Net web project.  If you think your stored procedures are still capable to do the job at the data manipulation level, you can redesign front end as web application.  This is preferred way for now, however as business owner you may not like the idea to redo it.
  • Complications.  You might have additional complications, such as tiered design, when your presentation layer is separated from business layer (or physically these two layers sit on different computers).  Then, somebody should carefully analyze and design the upgrade path for both.  Unfortunately business logic level may deploy third party vendors logic, and these flourishing ISV of late 1990th might be now out of business
  • Integrations.  If your Great Plains is integrated with Unix, Oracle, DB 2, Lotus Domino, Siebel or other third party application – you need to consider synchronous upgrade for integrated applications to avoid retuning integration piece twice.
  • Reporting.  Since version 6.0, Great Plains is very conservative to tables structure changes, so if your reporting was done in 1999 or later – more likely you are out of trouble and should use it as it is.

 

Happy customizing!  You can always appeal to us to help you with your system.  Give as a call 1-630-961-5918 or 1-866-528-0577, help@albaspectrum.com