Hi Harm,

Thanks for replies.

Quote Originally Posted by Harm Wibier View Post
As for embedded database string comparisons I would like to note that this is how it has always been when using SQL. It is very likely that 80% of the systems out there works on a SQL database that collates different than the DF_Collate.cfg of DataFlex does. So we do not expect big issues in that area.

We can't supply a standard DF_Collate that matches the new collation because the new collation is dependent on machine settings (unless you change it using DF_LOCALE_CODE). It might be possible to create a program that generates one based on the new collation. We are working on more documentation on this. But here is a forum thread with some details on DF_LOCALE_CODE: https://support.dataaccess.com/Forum...649#post351649
We still have an issue with the above. Just because "this is how it has always been when using SQL" does not mean its right and certainly wasn't something we were aware of until it bit us with some nasty consequences.

Take the example below. The SQL database collation is 'out of the box' which for our region is Latin1_General_CI_AS. I assume that the DataFlex runtime, prior DF20, took its string comparison collation from df_collate.cfg and hence why you see the result below. There are a couple of ways to fix this (sql) but the option we use is to change the df_collate.cfg file to best match the sql collation. Doing so gives us the results as if it were embedded.

Click image for larger version. 

Name:	2020-08-13_15-13-40.jpg 
Views:	81 
Size:	165.4 KB 
ID:	13898

In DF20 with "string comparisons in the language are now performed using the new Unicode comparisons". I assume that this will eliminate how we have used the df_collate.cfg file in the past. Therefore, how in DF20 do we match the database collating sequence? Is this where DF_LOCAL_CODE comes in?