--- In firebird-support@yahoogroups.com, David Johnson
<d_johnson@c...> wrote:

> asp.net and c# would have the same issue as Delphi with unicode,

since

> the problem is that the Windows native character set that all three
> products are married to is not wide enough to represent the full

unicode

> code space. Many Chinese characters are beyond the end of the two

byte

> code space allowed in UCS2.

mmmm, maybe I was just lucky with the chinese characters I picked but
I managed to achieve this relatively easily with a MS SQL 2000
database and Delphi. I basically duplicated the components on my form
and changed only the ADOConnection/ADOQuery on the "server tier" of
the application and could quite happily save and retrieve some
chinese I got off BabelFish. This led me to the conclusion that
either the db-connection/query (IBX) wasn't supporting unicode or my
database implementation itself wasn't.

>
> When you define the character set to NONE, the engine is agnostic
> towards the contents of the strings supplied. Corollary is that the
> application layer is fully responsible for the byte management of

the

> stored/retrieved strings.
>
> To support both English and Chinese well in the same database you

will

> need to move to an environment that natively supports a complete

unicode

> representation (UTF-8, UTF-32).

This sounds like what I want, I currently only need to support
English/Chinese, but hopefully I've designed it so that adding extra
languages in the future will be relatively simple (yeah right).
Having an "agnostic" database would fit ideally with this. If only I
could get it to work....

The comments later in this thread about regulations in China are
interesting - I wonder if they apply to Taiwan?