Martijn Tonies wrote:

>>> When connecting with a Delphi 2009 Unicode enabled Firebird
>>> connectivity set (connection charset becomes unicode_fss), on
>>> a certain database with no charset defined, I get the infamous
>>> "cannot transliterate character between character sets" error.
>>>
>>> Why can't a character be converted to Unicode?
>>>
>>> Anything specific here?
>> It's the other way round: converting Unicode characters passing from the
>> client to columns of charset NONE. Outside the 7-bit ansi range, in
>> charset NONE there is nothing to transliterate your Unicode characters to.
>
> Well, the error is raised on retrieval of data :-)

Hi Martijn,

the problem is that the engine does not know which character set to
convert it from. It only sees a bunch of bytes. Same bytes could be
different characters in, say WIN1252 or WIN1250 code page. So, it cannot
turn it into Unicode character, because it does not know which character
it really is.

This is general problem with NONE, which I call "garbage in, garbage
out" charset, because it is completely unaware of characters and you
cannot use any function that is character based (UPPER, CHAR_LENGTH,
etc.) reliably, because it would only work properly with ASCII set.

In short, if you absolutely have to deal with NONE, that use NONE to
connect to database and have the client deal with actual characters.
Please note that this means that ALL clients must work the same way.

It is much better not to use NONE at all, and use some real character
set which can then be transliterated. Then you can have some clients
(say, a Delphi app) connecting with UNICODE_FSS, others (say Java app)
with UTF-8, etc. and everything would work fine.

--
Milan Babuskov

==================================
The easiest way to import XML, CSV
and textual files into Firebird:
http://www.guacosoft.com/xmlwizard
==================================