Release of DataEase 7.2.2

DataEase 7.2.2 has been "slip stream" released in end of November. We have not wanted to advertise this release widely because we still have some fixes we want to include before it goes on general advertised release.

Release note DataEase 7.2.2

1. MIgration from 6.52

With the introduction of 7.0 of DataEase, it was decided that the coexistence 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 before use ASCII in Data and Business model, and OEM/ANSI for the GUI part. In 7.x we use Latin-1 UTC 8bit.

So before you try to migrate your application from 6.5x to 7.2 please make sure you observe the points below:

  1. a. Make sure you have a username/password on your application that do not contain any extended characters and that has full access to the application. The best is to remove or rename all usernames and password that contain anything but A-Z, 0-9 and Underscore. This should be a general rule in any case.
  2. b. Migration will only handle migration from ASCII character sets that is part of Latin-1. Migration of application that has used other character sets may work but will undoubtedly need extensive work either before migration or after.
  3. c. 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 too. To fix this either change this before you try to migrate the 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 some change like entering a space at the end of the formula. When storing the form, the change flag will  have been set and DataEase will recompile all the formulas in the form. As the formulas is correctly translated, the problem will disappear.
  4. d. 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 arrow point etc. When most migration of line objects will be straightforward, we cannot guarantee that 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.
  5. e. Introduction of , as optional decimal delimiter will work for entire application but DQL Procedures will fail to be compiled if a decimal number has been used directly in code. If this happens, the procedure will need to be recompiled again in the application 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 more than 10 years ago. With 7.0 DataEase moved away from its traditional way of handling extended characters, and in effect made it became impossible to use DataEase for people that used character sets outside UTC-Latin 1. 

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 is now supported.

3. Optional use of , as decimal separator for Migrated Legacy applications.

Decimal separator has 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 the decimal separator has up to 7.1 been read from Windows Regional Setting. DataEase has two ways of using code. Interpreting and compiled. The compiled code will work perfectly until one try to recompile it in a Windows that is set up with a different decimal separator. The interpretive code will go wrong the moment you start it up. This is why we in 7.2 has 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 you in your legacy application has used decimal numbers in derivation, actions, OML and DQL you can choose to fix the decimal separator on (,) instead. If you do this you will have to use this for all programming in the entire application.

There is two ways to switch on this fix. 1) You can select it directly in the migration too. 2) You can insert DecimalDelimiter=44 under the tag [INTERFACE] in the RDRRxAAA.INI file that you find in your application catalog.

4. Multibox

Multibox (Lookup in 6.52) has been extensively updated and changed in 7.2 and 7.2.2. We have to admit that multibox is not a favourite with us due to its duality, and we will in the future split this back up into too 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 ListBos 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.

5. OLEDB

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 is still some limitations.

  1. a. So far OLEDB does not Work in Windows 7 or Vista, this is not a DataEase problem but a general problem.
  2. b. DataEase OLEDB provider, do 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.

6. ODBC

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.


 

By: Ulrik Jacob Hoegh - Krohn posted: 17th August 2009 - 10:47


Comments

rwayda mohamed at 14th January 2010 - 11:22 says:

test test test

Please login to leave your own comments