Question : Should the == operator ignore collation or not?

Hi all

I just found a situation in which the == operator comapres two different strings as equal which is new for me... Did anybody of you observe such behavior already? If yes, could you please describe how to reproduce it?

My text strings do not contain specific national characters. Just english letters, digits, and some punctuation and/or operators. There is upper/lower case difference in two compared strings which should not be ignored by == operator.

TIA.

Answer : Should the == operator ignore collation or not?

I see what you mean, BROWSE FOR seems ok, but SQL not.

The == operator is rather only different from = in matching the whole length of both strings, it is not meant as always comparing binary or collation "MACHINE". So if you SET COLLATE TO "MACHINE" the SQL will only result in the exact match including case of the letters.

I rather wonder now, why the second browse does not compare the the SQL result. If rushmore would create a temporary index for the SQL but not for the FOR condition of the browse, that may explain it, but sys(3054) does not report creating a temp index and I'd also only expect that to optimize a join. Typically where conditions no index can optimise stay unoptimised and rushmore does not create a temp index.

I think that means you now will need to swich the collation sequence for some SQLs to give the right results.

I wonder if this is a newer bug or is there for quite a long time, I typically don't work with collation sequences and simply make index on UPPER(field) to have case insensitive sortorders. In german the problem is almost solved by that.

Bye, Olaf.