Mark Rotteveel [email protected] [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
