Ask the MultiValued Visual Basic Expert - #14

(as published in Spectrum magazine Mar/Apr 1999)

To email your questions to "Ask the MultiValued VB Expert", click here.
Copyright 1996-99 Caduceus Consulting. All rights reserved.

Stay MultiValue or go Mainstream?

Dear Andrew:

My corporation has an extensive suite of applications for the job shop manufacturing industry. It is proven software, requiring only one Pick/Basic maintenance programmer. Our plan is to make extensive use of web technology in a whole new incarnation of the package, and we now have a number of Microsoft Certified professionals on staff. I have read about your utilities to translate Pick/Basic code to VB. I am also gathering information on the many ways to connect Windows to a MultiValue database, such as terminal emulator GUI-izing tools, ActiveX objects, etc. Any recommendations? - G. Puffett, Data.Com International

Your question covers a very broad topic, but I'm sure that many readers can relate to similar situations, so I'll try to give you some meaningful advice, while keeping things sufficiently generic. Your intention is to migrate to a web-based package, and I gather that you are willing to completely rebuild the software (at least at some point).

The first thing that I note in your case is that you have more non-MultiValue programmers than MultiValue programmers. This is a significant factor in the selection of your migration strategy. In your case, terminal emulator screen painters that allow you to continue to work in Pick/Basic will have limited appeal. Also, if a complete rewrite is in the cards, then those GUI-izing tools are just stop-gap measures to buy you time.

The same reasoning can be applied to ActiveX objects (like D3 Objects, UV Objects, WinLink Objects, etc.). They are wonderful for giving you MultiValue Basic functionality from within VB, but that perk has little attraction to a mainstream VB programmer who is certified for SQL server.

There are tools that can translate MultiValue/Basic to Visual Basic - I developed one or two myself, which are referenced in earlier issues of this magazine (such as Nov/Dec 98). Their applicability in your case is based on which database you ultimately choose to go with. In the absence of more information, I would guess that you want to seriously consider SQL Server. Heresy, you say? Let's look at some of the decision makers, simplified for illustrative purposes (please - no debates or flaming email - I realize that these things are not black and white):

Factor

Answer

Is a complete application rewrite being considered?

No

Yes

Are technical staff predominantly MultiValue trained?

Yes

No

Is the intention to make use of the very latest leading-edge technology?

No

Yes

Are there many existing installations that would find system replacement very unattractive?

Yes

No

Does the software make extensive and innovative use of MultiValue-unique concepts?

Yes

No

Conclusion:

Stay MultiValue

Go Mainstream

Does this mean that your current application development investment is down the drain? Not at all. I would argue that the value of your software is 80% in the design and functionality and 20% in the actual code. Let's pretend that you are writing a whole new suite of modules from scratch. Your team of programmers is assembled, and suddenly a good fairy appears and hands you the most detailed set of software specifications ever devised: screen shots, data flows, business logic, prototypes, it's all there. At that point, the programming becomes a 'simple' question of cranking out code that performs according to the specification. My point is, if you consider your existing system to be a sophisticated form of system specification, it's retained value becomes clearer, even if you eventually toss all the code.

To email your questions to "Ask the MultiValued VB Expert", click here.
Copyright 1996-99 Caduceus Consulting. All rights reserved.
Added: August 18, 1999.

Return to Caduceus Consulting Home Page

Copyright 2006 intellact
Last modified: Thursday May 25, 2006