Hello,
The ABL is case insensitive by default, which means "a" equals "A".
Special characters (like ê, á) seem to be ignored when comparing to regular alphanumeric characters (e , a), ONLY when using EQ, not when using BEGINS or MATCHES.
ex:
DEFINE VARIABLE cChar1 AS CHARACTER NO-UNDO.
DEFINE VARIABLE cChar2 AS CHARACTER NO-UNDO.
ASSIGN cChar1 = "a"
cChar2 = "á".
MESSAGE cChar1 = cChar2 SKIP
cChar1 MATCHES cChar2 SKIP
cChar1 BEGINS cChar2 SKIP
VIEW-AS ALERT-BOX INFO BUTTONS OK.
We have tables like this:
DEFINE TEMP-TABLE ttCustomer NO-UNDO
FIELD custId AS CHARACTER
FIELD custName AS CHARACTER
FIELD custSearchName AS CHARACTER
INDEX idxCustId IS PRIMARY UNIQUE custId
INDEX idxCustName custName custId
INDEX idxCustSearchName custSearchName custName custId.
This problem shown above forces us to add an extra search field in our table, custSearchName, that contains the custName stripped from all special signs (+ - * , etc) and all special characters replaced by their non-special sibling (é, è, ë -> e). This is done by a function in the write trigger of the table. Only when using this extra field a user can search for "etabl*" to find customer "établisement Jean Louis".
Is there any way to circumvent this?
MATCHES
Most character comparisons are case insensitive in ABL. However, you can define fields and variables as case sensitive. If the expression preceding the MATCHES keyword is a field or variable defined as case sensitive, the comparison is case sensitive.
BEGINS
If either of the character expressions passed to BEGINS is a field or variable defined as case sensitive, the comparison is case sensitive.
You may want to check the [ CASE-SENSITIVE] options of DEFINE VARIABLE and table field-options, the COMPARE() function and the Internationalizing Applications product documentation: http://www.psdn.com/library/entry.jspa?externalID=1934&categoryID=464
In addition revise your collation settings (DBCollation and -cpcoll startup parameter). The defaults are case-insensitive. E.g. KBase: http://progress.atgnow.com/esprogress/jsp/AnswerControls.jsp?directSolutionLink=1&tabs=true&docPropValue=20696
HIH
If I use a utf-8 session:
pro -cpstream utf-8 -cpinternal utf-8 -cpcase basic
the result is correct: cChar1 is not EQ cChar2
I belive you need to check the collation table. For German special characters (äÄ öÖ üÜ) it's the same issue and the callation table (German9) controls that an ä = a (no matter of the case).
I'm pretty sure there's also a French collation table - but I can't check this as I only have German and English on my PC.
Hello Salvador,
My CHARACTER variables are not case sensitive. How come EQUALS acts differently from BEGINS and MATCHES when comparing special character (like á and à)?
greets
Hi Lieven,
It has to do with the comparison strengths (e.g. RAW, CASE-SENSITIVE, CASE-INSENSITIVE, CAPS), combined with the use of collation tables or not. In addition note that in this discussion we are mixing at least two concepts: Caps and Special-characters. In the product documentation you can find information about ABL comparison strengths as well as those specific to ICU collations.
Finally, let me tell you that your questions are very timely because we are working on making the comparison rules of EQ, BEGINS, MATCHES and other operators clearer and easier to use with regards to case-sensitivity, special characters and the use of collations in i18n configurations, without introducing undesirable behavior changes to existing applications. It is a work-in-progress, thus we do not have final plans or a committed release date yet. Stay tuned to our regular communication channels.
Best regards
Salvador