Conversion Strategy

Despite the high level of compatibility between the various versions of FoxPro and Visual FoxPro, converting from one to another is never going to be a purely automatic process. The closest that you can get to this is the route of Functional Conversion but, although this will be a very quick process which requires minimal effort, you will deliver a product which looks like a ten-year-old application from Windows 3 and which has none of the modern facilities which users have come to expect.

The work of converting the program logic and the data structure is minimal. All the hard work comes with the conversion of the user interface. This work falls into three categories:

• Object orientation
• New controls
• New style

Object orientation

The conversion to object orientation is due to the change in the programming model from 2.6 to Visual. Visual FoxPro includes two converters which will do the bulk of that work. These converters are not perfect but, if it were not for the other two factors below, then we could live with their shortcomings.

New controls

New controls have been introduced to the Windows user interface since FoxPro 2. We now have grids and pageframes in FoxPro, we have access to a wide range of ActiveX controls, and we have the ability to provide seamless links with office software such as Word, Excel and Crystal Reports. Users appreciate the ease of use that these new features have brought and they would not like to see them missing from their "new" database.

Style

FoxPro 2.6 ran under DOS, Windows, Macintosh and Unix. The style of the user interface has changed a great deal since then and the converted database would look very out of place on a Windows XP computer if it still used the colours, fonts and styles of Windows 3. A modern application makes much greater use of graphical elements whereas a converted FoxPro 2 database will use text everywhere.

Why stick with FoxPro?

Given that the best way of converting the database is to rewrite it then the question of which language to use must be considered. There are two major advantages to sticking with Foxpro: language and data structure:

Language

The user interface is only part of a database application. The logic behind that interface exists as procedures and functions in FoxPro 2 and these procedures and functions can be transferred unchanged into Visual FoxPro. If a completely new application were to be designed and built in Visual FoxPro then these algorithms would be implemented as methods of classes. Even then though, the methods have to be written using the FoxPro procedural language and much of the code from the FPW routines will be used unchanged.

Data structure

Visual FoxPro supports all the data types used in earlier versions of FoxPro for DOS and Windows. The only unsupported type from earlier versions is the Macintosh Picture type but, as VFP no longer runs on Macintosh, that is understandable. If the database were to be rewritten in another language then there would be issues with the minor incompatibilities and inconsistencies in data types. Names of tables and fields may also have to be changed so you will need some sort of master cross-reference document.

Visual FoxPro can share data files with earlier versions of FoxPro. If a new database were to be used then all the old data would have to be converted and all users would have to change simultaneously and completely from the old to the new system. There would be no possibility of easing the transition with a period of parallel running and no possibility of reverting to the older system in an emergency. The data compatibility between FoxPro and Visual FoxPro allows you to take an incremental approach to the changeover.

You can start the changeover by converting just one module of the application to Visual FoxPro. If you build that module as a self-contained executable then you have two ways of integrating it with the old application. One is to remove that option from the old menu and give the users a new shortcut to the new module on their desktop. The other is to modify the old menu so that the appropriate option actually calls your new module rather than using the original code.

The possibility of parallel running, of an incremental changeover, and of having the fallback position of reverting to the old application makes an upgrade from FoxPro to Visual FoxPro very much easier, cheaper and less risky than a conversion to another language.

Introduction | Data | Program code | Menus | Reports | Screens | Strategy