Migrating from DFW 5.x and 6.x to DE8.5 including National Versions

If you want to encompass DataEase problems in one word it must be Migration. It is fascinating that a company that has had so little success with this concept, has sworn to it for such a long time.

It is a badly hidden secret that DataEase lost most of it users in the flawed and bodged migration of DFD application to early DFW, what is maybe not so well know is all the other "unsuccessful" migration events.

In this article we will explain what/why and how it went wrong and what you can do to work around it.

DFD to DFW 5.x

It might seem mad in hindsight but when DFW was developed the idea that people should move their DFD version to it couldn't be further from anyones mind. The goal was not to preserve the 3 million +  users world wide, but to become a major player on this new and exciting platform of Windows, Client/Server (SQL, Oracle DB2..). Any migration attempt from DFD to DFW 1.0 (Express) was more or less added as an afterthought and since Express was designed as a SQL frontend, the troublesome DQL was not included.

Needless to say the combination of Lack of functionality (DQL), change in functionality, awkwardness and unfamiliarity added to a cocktail of new and old bugs, character set problems etc. insured that a majority of DFD users never took the leap.

DFW 5.x to DFW 6.x
One would assume that by now DataEase had learnt its lesson and on the surface of things we had. 6.x was still compatible with DFD so the PRISM side of things should offer no problems, or so one would think.

But as it turned out, running a DFW 5.x in 6.x showed up a lot of previously unknown problems, simply because when DFW 5.x was 16 bit, one of the big "news" in DFW 6.x was that it was now "fully" 32bit. With fully 32 bit one really meant that everything was as before, but the code was compiled with a 32 bit compiler so it would run in the future 64 bit operating system (yes, you don't need 32bit code to run in 32 bit OS...but you need that to run in 64 bit...). In fact 32 bit code is more effective in 64 bit than 64 bit so the benefit is basically just in addressing and size, not in speed.

Anyhow, the "benefit" of moving the code from 16 bit to 32 bit compiler is that everything takes twice the space, so all the buffers that was already too small in DFW 5.x was effectively halved! So if you had been pushing the boundaries of DFW 5.x when it comes to sizes and number of derivations, validation etc, you now was way passed with the exciting result it wouldn't run/work.

Strangely enough there is very little understanding amongst users when a new product has more limitations than an older version. Another bunch of users couldn't move forward... 

DFW 6.x to 7.x
But surely! Now DataEase learnt the lesson and would make a smooth migration or no migration at all. NO! By changing strange things as the lenght of Table Names, Character set from one 8 bit to another (yes, not to something contemporary), changin Memo fields completely, removing Menu documents, and again changing compiler from Borland to Microsoft the success was assured. 

With something as complex as a Developmetn software one should really only change one thing at a time and then test the effect rigorouosly, but DataEase decided to do the opposite. Change a lot of things that the users won't see or benefit from (initially at least), and throw in a lot of new trouble, hassle and bugs yet another time.

Again the user couldn't just move from 6.x (or God forbid 5.x) to 7.0, 7.1, 7.2... So another batch of people had to stay behind.

DFW 8.0 and 8.1
To be honest, we removed the migration tool from DFW 8.0 and 8.1 simply because it did more harm than good, so the main difference of the first 8.2 from 8.1 was migration from 6.x to 8.2. We re-introduced Menu documents, old-style memo as LongText, extensive OML fixes and a lot of other small and big changes to accommodate the move from 6.x to 8.2. When we were happy that an English 6.x app would move more or less trouble free from 6.x to 8.2 we released it and the updated migration tool.

However.... it wasn't good enough.

We knew that Sapphire had ignored the international side of things, and out of necessity so did we. It was just too much to do, so we needed to keep on the straight and narrow.

When an opportunity arose and we got a request to migrate a Norwegian DFW 5.x application, we leaped at it and way was it an eye opener of how hard life has been out there.

The migration tool has always been a patch work, and parts of the code go all the way back to the RNA and DNA of the original DataEase for DOS. I wouldn't go as far as saying that the code in the main product is always perfect, but it would be an understatement to say that the code of the migration tool is shoddy. Hard-coding, work-arounds and patching seems to be the order of the day. Maybe because it will only be used "once", but what an important "one off" that is.

With the DE 8.5 version of the Migration Tool we are relatively sure that you should be able to move any DFW app from  5.14 through to 6.53 to 8.5 without too much trouble.

To accommodate the different character sets used for national versions, we have had to use a converion file that need to be included with your DE8.5 (Higher or equal to 8.50.1757) called convert.mig.

The one shipped as convert.mig is the one that correspond to the one shipped with DFW 5.x and DFW 6.x English.

To convert, Norwegian, Danish, German etc. Simply select the corresponding Norwegian.mig etc, and rename that to convert.mig before you start migration.

When you mgirate DFW 5.x app, there might be incidents where the DFW 6.x code used in the migration tool will not be able to cope and give errors (this is mainly during re-compile). Don't worry. We have included a fall-back which will use the convert.mig algorithme in runtime if your old tables etc, can't be migrated properly so it will all work when you run the app in DE8.5 as long as you include the correct convert.mig with all your DE8.5 installations.

Download Migration Files

In the attached file you will find the migration files for Norwegian, Swedish, Finish and Danish.

As far as we can tell, all other languages used the international (i.e. default convert.mig).

If this is not true, please forward us the demessage.msg (.swe, .nor. .dan, they had a tendency to have national extension) that you used with your legacy dataease and we will create a convert.mig for your language.

PS! You will need to use the latest Beta II, you find it in download

Where to find the migration tool in different windows versions.

Up to and including Windows 7 and in Windows 10, The Migration tool is found in the DataEase Group on your Start-Menu or directly in your DataEase catalogue.

This is the view on a x64 Windows 10 machine but it will be similar in Windows 7.

In Windows 8  the Start-up Groups are removed, so you simply need to search for Migration Tool in the Tiles screen or locate it it directly in the program catalogue.

Make sure you use the correct DataEase 8.x catalogue.

Published: 11/03/15 - 10:19:11 (Amanda Higgins)