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):
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
