Download 8.1 Beta here!
You will need a license key to install it, but you can use a trial key or your full 8.0 key (It will install parallel to 8.0 and will not interfere with 8.0 in any way, but beware that you should not open/work on a 8.0 application in 8.1 and then continue working on it in 8.0)

DataEase Beta use an "outdated" installation package so you will get some error messages and it will not show the license number etc. correctly, but just ignore this as the Beta will work fine.

The big changes in DE 8.1 is:

1. Re-introduction of DFW 5.x/6.x Memo as LongText (Text field has been extended to 4080 characters) and old style Memo will be migrated to LongText rather than memo. This will give impressive performance improvements in 8.1 in comparison with old style Memo being migrated to New style memo in 7.x. LongText in 8.1 is also improved in comparison to Memo in 5.x/6.x. You will be able to search all of the LongText field with traditional DE search when you before could only search in the first 255 characters. LongText will also work properly with lookup/derivation and you will also be able to use them as virtual fields.

2. Menu Documents is re-introduced. Menu document was removed in 7.0 and the reasoning was that Menu documents was "outdated" and that it was only a Form without Fields anyway. The reasoning might have been sound, if it wasn't for the fact that the human brain doesn't necessarily work the same way as a computer. We like organising stuff visually and the fact that Menus was grouped together and we intuitively knew what they were there for, helped a lot.

Another rationale was that the second "speciality" of Menus - chain menus - could be implemented as control procedures instead and it was not natural to use Chain Menus in DFW. We have to agree and disagree with this, it feels a little "strange" to build a graphical menu with buttons in DFW and then it gets executed automatically in order (tab order). So we might have agreed with the rationale if the other part of the "deal" had been kept up i.e. that old style menus was automatically migrated to Forms in 7.x.

As it turns out, they never were and even though this has been "touted" it wasn't even attempted in the code in now turns out. So basically Menus was just stripped away from the migration/app which again would leave the application hanging in thin air after a migration.

We have re-introduced them "meticulously" the same way as they were and we have realised that it is a very useful document and that chain menu is quite nifty even in DFW if you just get over youself and the fact that you are making a graphical document you won't ever see.

However the main reason for re-implementation is that a 5.x/6.x app should work from day one in 8.1 without any necessary changes by the user.

3. GPF - A lot of Forms/reports would cause GPF when opened both in DT and RT after migration in 7.x. This is of course another show stopper. Only GPFin in RT one can live with, since one can work around it in DT if one know what causes it, but GPF in DT is an end game.

As it turns out it was just bad programming in 7.x where objects being used for things they were not intended for in 5.x/6x and due to this objects were not terminated correctly in 7.x and GPFed.

4. OML.
Here we have fixed quite a lot both for migration and for OML use in general. OML would be part of the problem in 3, but also a problem on its own with use from scratch in 7.x.

The problem was that you worked on OML and suddenly it would GPF. When re-starting, one would discover that the Form would GPF in DT too so one had lost all ones work. This is psychologically very unfortunate and something that is the "death" of new functionality.

In DataEase one of the big discussions have over the last 20 years been "stability" and for users of other tools this must sound very "quaint". One must assume that the product is stable, and the fact that DataEase has not been able to lay this discussion dead, say a lot of the lack of direction/knowledge and focus of the development team.

We realise that things need to work, and that it definitely need to work in DT even though things can go wrong in RT (testing). So one of the big changes in 8.1 OML is that it will "always" open in DT even though it GPF in RT. This is done simply by checking the integrity of the compiled OML code and if the integrity is dubious DataEase simply disable the compiled code and you will need to re-compile it in DT.

Even though this might be an inconvenience it will only happen when you develop the application and it much less of an inconvenience than loosing your work for ever ;-)

5. Multibox/Lookup.

This 7.x update to the Lookup field has been wrought with problems and inconsistencies. We have updated it before, and now we had to do it again. Lazy programmers had re-used flags and features from removed items in 7.x which has caused problems throughout the 7.x/8.0 era for this feature. With re-implementation of LongText, Menu etc, we had to sort this out and don't be surprised if migration of Lookups now works, when it before didn't. Multibox should also work more consistent and stable.

This is not the release version of 8.1 but for people that want to migrate from DFW 5.x/6.x should already use this version to do this. The rest of the changes in 8.1 before release is mostly cosmetic.

The main goal in 8.1 is to bridge the gap between versions that was created pre 7.x. It is not a fix for DFD migration problems, but you will however be able to migrate DFD 5.x tables/data to 8.x.

There has been a lot of good intentions in DataEase development over the years, but for reasons we won't bring up now these intentions came to naught and in consequence caused problems instead of helping the users.

The big one is of course the horrible lack of compatibility between DFD and DFW back as far as 1994/95 but another an less discussed one is the one artificially created between DFW 6.x and DFW 7.x. Up to DFW 6.52 (LegEasy Windows 6.53) DataEase kept the data format consistent and compatible with DFD. There is no difference in Data structure between DFW 5.x, DFD 5.x and DFW 6.5x. All of this however changed dramatically and needlessly in 7.0.

One just have to believe that this was done with the best of intentions, but as the big one in 1994 it was very "un-educated". The changes done in the file format that finally left DFD was not utilised in any way in 7.x so in hindsight it would have been much better for everybody if the format had been left un-changed.

We think that the motivation was more that one wanted to move forward and get rid of the DFD influence but it wasn't successful and when the rest of the changes was of bad quality and migration from 6.x to 7.x left a lot of objects not migrated (Menus, Lookup fields etc). and poor performance it was easy for people to again "shun" 7.x and stay in 6.x.

Both the users and we need to move forward, and it is our job to make sure that the future is better than the past and 8.1 is a step on the way for that.

We will gradually build down the fences and bridge the gaps between the past and the future and we know that moving to 8.1 from earlier versions of DFW will only give fantastic benefits.

First step is to get a trouble free migration without any need for manual work/amendments and then the floodgates open:

You can start developing with all the new functionality, start thinking/building a Web Portal and soon start reporting on your data in DE Live Reporter.

You will also be able to access your old data with our new ODBC driver for "legacy" DataEase.

The future is bright!