DataEase 7.2.2 is a major update of 7.2 that includes fixing of external data drivers, as well as language support and an extensive fix list (see separate article). This article should be read by all 7.2 users.
1. Migration from 6.52
With the introduction of 7.0 for DataEase, it was decided that the co-existence with DFD was too restrictive for DFD and this was abandoned and one did again decide that migration was the way forward. Any migration is a expedition into uncharted territory and the migration from 6.5x to 7.x has not been straightforward either. When working with these intricate challenges, we have had to allow for some hard restraints that need to be observed for this migration. The biggest challenge has been the fact that 6.5x and previous, use ASCII in the Data and Business model, and OEM/ANSI for the GUI part. In 7.x we use Latin-1 UTC 8bit.
So before you migrate your application from 6.5x to 7.2 please make sure you observe the points below:
Make sure your username/password to your application does not contain any extended characters and you have full access to the application. It would be best to remove or rename all usernames and passwords that contain anything but A-Z, 0-9 and Underscore. This should be a general rule in any case.
Migration will only handle migration from ASCII character sets that are part of the Latin-1 character set. Migration of your application that used other character sets may work but will undoubtedly need extensive work either before migration or after.
If you have used extended characters in field/column names, these will cause errors when you migrate, as we are not able to change the compiled part of the formulas from the migration tool. To fix this, either change this before you migrate your application, or simply trigger a recompile of the table/form after you have migrated. The easiest way to do this is to open a field, go to the BRL(Formula) and make a change such as entering a space at the end of the formula. When storing the form, the change flag will be set and DataEase will recompile all the formulas in the form. As the formulas are correctly translated and the problem will disappear.
The line object has changed radically from 6.52 to 7.x. In 6.52, the line object was only a line object, but in 7.2 it is also a pointer object with an arrow point etc. Most migration of line objects will be straightforward, but we cannot guarantee the visual result will be the same in 7.2 as in 6.52, so please check your line objects and correct them in 7.2 if they display incorrectly.
Introduction of a comma (,) as an optional decimal delimiter will work for entire application but DQL Procedures will fail to compile if a decimal number has been used directly in code. If this happens, the procedure will need to be recompiled again before it can be used.
2. DataEase and extended letters
DataEase has for a long time ignored languages outside the English language group. The last Language version was in DataEase for Windows 5, which was more than 10 years ago! With 7.0, DataEase moved away from its traditional way of handling extended characters, and in effect made it impossible for DataEase applications using character sets outside the UTC-Latin 1 character set.
One of the biggest changes in 7.2.2 is that we have now prepared the product again to handle language versions. With 7.2.2, you can use any 8-bit character set supported by Windows. So all languages from Greek, Russian, Arabic to Simplified Chinese are now supported.
3. Optional use of a comma (,) as a decimal separator for Migrated Legacy applications
Decimal separators have always been a problem in DataEase. In legacy versions of DataEase, this represented no problem, as the application would not travel between language versions. In DFW, up to version 7.1, the decimal separator has been read from the Windows Regional Settings. DataEase has two ways of using code. Interpreted and compiled. The compiled code will work perfectly until one tries to recompile it in a Windows environment set up with a different decimal separator. The interpreted code will go wrong the moment you start it up. This is why we, in 7.2, have fixed the decimal separator to the standard for programming (.). This will not cause problems if you haven’t used decimal numbers in your programming. On the other hand, if your legacy application has used decimal numbers in derivation, actions, OML and DQL you can choose to fix the decimal separator using (,). If you do this, you will have to use this for all programming code in your application.
There are two ways to switch this fix on:
You can select it directly in the migration tool;
You can insert DecimalDelimiter=44 under the tag [INTERFACE] in the RDRRxAAA.INI file, which you will find in your application catalog.
Multibox (Lookup in 6.52) has been extensively updated and changed in 7.2 and 7.2.2. We have to admit that the multibox is not a favourite with us due to its duality, and we will in the future split this back up into two controls.
Multibox as Lookup:
The Multibox can be a little difficult to understand due to this duality, but to use it as a straight forward lookup as in 6.52, it is now more straightforward. As we have introduced a Relationship restraint override, you can use any relationship between the current form and the table you want to populate the Multibox from. To take advantage of this feature simply check Show all records. This functionality will be the same as the old trick of defining a relationship with no columns restraint, just the two tables.
Multibox as ListBox or ComboBox:
You can choose to configure the Multibox as either a traditional ListBox or as a ComboBox. If you check Allow Free Input, it will be a ComboBox where you can either choose from the dropdown or type in any value you like. If you don’t tag it, the multibox will only allow values in the dropdown and will auto complete when you have typed in enough characters to identify the choice as Unique.
MultiBox as MultiBox (Old CTRL-F10 Functionality):
The idea behind the MultibBox was to incorporate the CTRL-F10 lookup in a control that could be configure. We think this is a novel idea, but it should never have been mixed with the Looup. The idea is that one can show corresponding columns to identify a coded return, that will be saved in the parent form.
Since the Multibox in essence is a traditional ComboBox, this functionality is flawed. You can still use the Multibox with multiple values in the dropdown, but the return (Bound) value need to be the first in the list, and it need to visual. In future versions we will introduce a seperate CTRL-F10 control, where the return value will be hidden if you so choose, and only a button will be visible.
OLEDB is basically a simple SQL interface to DataEase. This functionality has been around since 6.52 and has been a good way of reading DataEase Data between different DataEase applications, as well as allowing other tools to read DataEase Data.
This functionality has been more or less broken, throughout the 7.x era. In 7.2.2 we have fixed this but there are still some limitations.
So far OLEDB does not Work in Windows 7 or Vista, this is not a DataEase problem but a general problem.
DataEase OLEDB provider, does not convert your column names, but provide them as they are stored in DataEase. If you have used space or extended characters in you column names, the select statements generated by some tools will not be valid, and the select will fail. To avoid this make sure that you only use A-Z, 0-9 and _ in you column names in DataEase in tables that you are going to provide through OLEDB. (This is a good rule in any programming anyway, and we will automatically enforce/convert this in DataEase G3). DataEase OLEDB Consumer is amended to send select statements that will allow for the above.
ODBC has also been broken throughout the 7.x era, and have now been extensively fixed and tested. ODBC will now work for all version of windows from XP to Windows 7, including 64x versions, but be aware that you manually have to configure the use of ODBC in WIndows 7.