When using the Import Data utility with Import Format Type: "DataEase 5.x - 8.x" the date field values are lost.
if the original data is exported as Variable length text delimited format the date values import works.

Anyone know how to get round this issue other than using the delimited text option?

Same issue found on DE 7 and LegEasy 9  (was not an issue before on DE6 & earlier)

LE9 beta 7292 still has the same issue with previous version dates on dbm import

This is put on a list but as this code has not been touched more or less since 7.x it's not a priority.

Importing from DataEase files is an obsolete functionality as most people export data for import rather than exchange database files.

We haven't tested this but we think this has been like this since the switch from 6.x to 7.x as there was a lot of trouble with date configuration in DE6 hence migrating the data correctly was a problem.

The problem with the export to delimited format is that the number of records that can be exported is limited. For tables with more than 500 000 records it often fails with an insufficient memory error. This can be sorted by filtering and exporting the data in smaller sets.
Delimited text format export with tables containing complex derivation virtual fields is very slow and/or fails. The remedy for this is to remove the virtual derivation before export.

The DE dbm import is a lot faster as it does not require the initial export and is not affected by virtual derivations.
DE DBM import from DE7 into DE9 also has the same date field values lost issue.

What process du you use for exporting?

From experience we know that your app is quite big and complex so you might experience problems most users never experience.

Do you use DQL with .export, execdql export or the built in export feature?

Mostly the built in export.
DQL export is slower and has similar memory failure issues.

TO be honest we have never experienced that the built in export/import has crashed but the .export feature in old style DQL is know for failing and being very variable with speed.



Have you tried this export?

That feature may be useful in future to export in DE9 but it is not available in DE6 or DE8.
The issue is for DE9 be able to retain the date field values when using a DE6 DBM import.

As annoying as this might be this is not something that will be addressed.

The problem is simply that someone did a big mistake in DE6 so the configuration setting in CONFxAAA.DBM is ignored and the data is stored in 
US format even if the application is configured for INTERNATIONAL.

As you can see from above in the "club" app, the date is shown in UK/Europe format but in reality it is stored in US format (MM/DD/YY). 

So when you try to import it into DE8 or DE9 it will be "invalid". 

You will see the same if you try to migrate an applicaiton from DE6. If you say read from configuration its a hit or miss if it gets right. You will have to choose the correct format (trial and error in most cases) 

To have a sucessful migration you need to change the setting in CONFxAAA.DBM to US rather than International 

This will be 02 in your application but will be ignored by DE6 but not by the migration tool so need to be changed to 01 for the migration to be successful (migration of date fields).

The import feature will only import like for like as there is no information stored in TDF/DBM about the format of Dates so if you are to import .DBM files you will need to have the same date format in both applications.

If you try to import DBM files from DE8 to DE9 you will see it is fault free.

So the problem moving forward from DE6 si DE6 itself and not what you are moving to with a healthy exception of the entire DE7 range.

Thank you for the info.
Will see if it can be used to sort a workaround.