I am trying to convert a V4.53 database to V8. I have upgraded it to V5.50 and have opened it in V6.52 - So far so good!

I have made a Backup, created a new application in an empty folder (The application is called exactly the same name) and am now trying to restore the Backup to the new application when I get the message shown above.

As far as I am aware the original application was written by a firm that have long since disappeared and I assume that they used the Developer software to do so.

How can I (If I can!) get round this problem - I am sure that there are other databases out there that have been written using Developer and will fall at this hurdle too!

The immediate problem is that the encryption was created to stop the customer and other developers to "steal" the IP so what you try to do is exactly what it is designed to stop you from doing.

In principle you should only be able to decrypt the application if you know the encryption key.

Challenges in DataEase when it comes to stuff like this is two dimensional and perpendicular to each other... Old functionality has been brought forward from the dawn of day in DataEase so things that was implemented in DFD is still "the same" in 8, but on the other side will a lot of new functionality implemented in DFW completely disregard the rules that was established by previous developers.

The Developer Encryption stuff was only "live" in DFD but it was part of of the DataEase "sphere" up to the change in data format in 7.0. It is obvious that the team that did the re-write in 7.0 wasn't aware of this feature or simply ignored it as this is where the disparity appeared.

From 7.0 onwards this is no a supported or acknowledged feature but a lot of old functions still adhere to it and that is where the problem arises.

We had a similar problem not many weeks ago and we where then able to rescue a majority of the application and move it to 8.1, however this application was started in Developer but a majority of the functionality was developed in DFW 6.52 which might have made a difference.

There is no straight forward receipt on how to do this, but if it is important we can have a look but it will be chargeable.

Hi Mr. D.

I have got round the problem by not trying to create a 'tidy' copy of the V6.52 data but by simply running the V8.1 Migration utility on the 'untidy' copy. The (Quite small) database looks OK in V8.1 on first glance and, as I believe that there are not going to be any Backup & Restore functions in DataEase in the future, the restore problem has gone away!

I have migrated two different databases today in DOS on an XP machine, one small and one very large - In both cases the Migration utility dropped out at the end with an Exception Error and then gave the number of Errors and Warnings it had produced. In both cases the databases seemed OK but neither Migration LOG file could be found.

To be honest, this is why migration in itself is such a bad idea and especially the approach that DataEase has taken over the years.

The worst approach is to try to migrate "apples into pears" which was the migration attempt in DFW 5.x and from 6.x to 7.x. This invariably cause a complex matrix of possible errors that it "must" go wrong.

That is why in 8.1 we went the other way and re-introduced the functionality removed in 7.x so we could migrate "apples into apples". This has improved it a lot but the utility is the same one that has always been there with the same weaknesses.

One major weakness is that it is "all or nothing". The right approach would have been to create a tool where you had a proper interface and could select what to migrate and if it went wrong, Documents were tagged as "corrupt" and omitted in the migration. One should also be able to do migrate an app manually by migrating one document at a time.

The main problem is however that DFW is based on binary code (compiled memory) so you are working with memory pointers which can cause GPF if a document is corrupt. With the number of versions (with their different bugs) that an app has been through the possibility of a document being corrupt in one way or another is quite high, so this is why the "all or nothing" approach is in reality a non-starter.

Our problem is that we have to much new stuff to do and a lot of stuff that should have been fixed (working) by the previous team so we have to prioritise.

The feedback so far is that the 8.1 migration tool is much more solid than previous versions, but it is far from perfect.

There is a strict limit to how much time we will and can put into improving it, but if there is obvious and common shortcomings we will fix it.

The only way we can find these problems is if the people that have them send us the application and a clear instruction on what and how to replicate the problem. We will then run it through the debugger to see if there is an obvious reason to why it GPF.

GPFing is much less prevalent in 8.x than in other DFW versions and this is because we have spent quite a lot of time on "exception" handling. Before it would simply GPF but now we try to catch it and handle it properly.

What may be a clue to the cause of the Exception Error is that both databases had been taken from V4.53 to V5.50 WITHOUT ANY DATA, so that they were just the tables, procedures etc.