So far so good. Apart from some cryptographer code that required refactoring, our application source compiles and runs. Undoubtedly, we still have work to do before it’s UNICODE ready and with that in mind we have decided to leave 64bit for another release.

Reading the available literature, am I right in thinking these are the main areas of source code that need reviewing?

  • Length function. Are we counting characters or the size of the string? May need to switch to SizeOfString.
  • Sequential I/O. Where we are using direct_input/output do we need to maintain the existing file format or add a BOM to identify the file as UNICODE?
  • External APIs. Identify which ‘A’ calls have an equivalent ‘W’ call and update accordingly.
  • 3rd Party Controls. Review and update accordingly.
  • MSSQL. Convert char and varchar datatypes to nchar and nvarchar data types respectively.

Our customer base is still a spread of embedded and SQL at this time but the pendulum is slowly swinging towards SQL. Note our applications don’t support mixed database environments. It’s either one database type or the other and this includes tables such as codemast etc. With that in mind I noted the following in the What’s New.

Database
The embedded database does not support Unicode and data written to it is converted to OEM by the runtime. It is backwards compatible and the database can be shared with older revisions of DataFlex. The sorting of the indexes is done according to the Df_collate.cfg in bin or bin64. Note that string comparisons in the language are now performed using the new Unicode comparisons and can be different than the embedded database collation.

All that is ok with exception of the string comparisons. In particular where a control block e.g. while / loop is used to step through a table and the primary index segment is a string. If the database collating returns records in a certain order is there not the potential for the loop to terminate prematurely since the string comparison evaluation will be different?

If that is the case will DAW provide a DF_Collate.cfg that matches the string comparison used by the runtime?

Under the Collating section there is mention of a new attribute called DF_LOCALE_CODE. From what I gather this doesn’t apply to the embedded database. I was thinking we could use something similar to set a custom df_collate.cfg. NB: I appreciate the database would require reindexing.

There isn’t much information on this new attribute. Could someone please explain how it might be used and when?