Mark Rotteveel mark@... [firebird-support] wrote:

> I think this is a bug and it should be reported as such. If
> there is no uppercase equivalent of a character in the current
> character set, then UPPER() should use the character itself,
> not throw a transliteration error.

I tend to agree, but wasn't certain whether it was intentional.
It is easily tested on these SBCS (which is how I am now
confident that this was the only character with the problem in
WIN1252), so it seemed possible that it might be by design.

I will report it and let the developers decide.

> However, have you considered using a case insensitive
> collation instead of using UPPER() (assuming the actual
> problem is with comparisons, not with displaying uppercase
> characters)?

I first found this problem when trying to fix some of my own
code that was calling Upper() unnecessarily when constructing
the SQL - because the blob field in question does use a case
insensitive collation.

Regrettably, fixing my code to remove the unnecessary Upper()
call did not fix the problem. A simple CONTAINING test on
the blob still gets the error - presumably because it does
the same upper-case conversion internally to achieve its case
insensitivity.

--
Geoff Worboys
Telesis Computing Pty Ltd