Commented by: Fabio Gomes (fabioxgn)

Hi, Is this a bug? Will I have any problems if I downgrade to Firebird 2.5.2 without a backup/restore? I've found this problem with more databases and it's complicated to fix the data.

Commented by: Geoff Worboys (gworboys)

An alternative example to work from:
SELECT Upper(_win1252 'ƒ') FROM RDB$DATABASE

Or see these:
SELECT Upper(_win1252 x'80') FROM RDB$DATABASE -- works
SELECT Upper(_win1252 x'81') FROM RDB$DATABASE -- works even though not a valid WIN1252 character
SELECT Upper(_win1252 x'82') FROM RDB$DATABASE -- works
SELECT Upper(_win1252 x'83') FROM RDB$DATABASE -- FAILS
SELECT Upper(_win1252 x'84') FROM RDB$DATABASE -- works

From my post on the forum:
Internal to Firebird the string is converted to Unicode, so WIN1252 0x83 becomes U+0192. This is then converted to uppercase which becomes U+0191. And then it tries to convert back to WIN1252 and there is no WIN1252 mapping for that unicode character (U+0191).

As far as I can tell (doing a test against all 256 characters) 0x83 is the only character in WIN1252 with the problem.

Note that WIN1253 also has a similar problem (I don't use it so didn't investigate the specifics).

To solve this in my own FB build I just added a mapping from U+0191 to 0x83 for WIN1252 - but I don't know if this is considered acceptable to a wider audience because presumably it would mean that WIN1252 would accept U+0191 in all transliterations (not just Upper of existing data) which may not be desirable (but is not important to my application).