| Subject | Re: [Firebird-Java] Re: Cannot transliterate character between character sets |
|---|---|
| Author | Helen Borrie |
| Post date | 2004-01-12T00:06:20Z |
At 10:30 PM 11/01/2004 +0000, you wrote:
NONE-to-SOME_CHARACTER_SET columns, if the stored data already has the
correct bytes, is to cast the data to character set OCTETS and store that
directly into the character set-whatever column. But I don't see how it
would work for unicode, because the actual bytes in the character codes are
totally different.
Is there any special reason why you need to convert to the data to unicode
rather than ISO8859_2?
Other details you haven't mentioned include what the default character set
is for your database and whether you are setting your client connection's
lc_ctype param correctly for it (sorry, I don't know the Java class but
it's one of the "basics" for connection).
capability. There's a list in the Downloads > Contributed area at
www.ibphoenix.com, some free, some not.
If you are on Windows and you know your SQL well, the free IB_SQL tool at
www.ibobjects.com has a datapump that sets up a cross-database transaction
between the source and the target dbs. You set up the source (a SELECT
statement) and target (an INSERT or UPDATE statement) exactly as you want
them. You can map the source fields to the target fields
individually. When you run the pump, the output from the source is
streamed directly to the target. It's a two-phase commit, so if something
falls over, the whole lot will fail and can be rolled back. Using that
tool, I'd first try a simple select on the source side and cast the input
on the target side.
HB
>--- In Firebird-Java@yahoogroups.com, Helen Borrie <helebor@t...> wrote:One tip I heard from somewhere, when you have these
>
> > select
> > cast(charcol1 as varchar(40) character set unicode_fss) as
>charcol1_u,
> > datecol,
> > ....
>I tried cast(msg as varchar(50) character set unicode_fss) as msg_u
>but after this, the transliterate error came not only when inserting
>hungarian chars, but after the first row, that was totally english
>I have varchar(255) types I want to convert to unicode_fss :(
NONE-to-SOME_CHARACTER_SET columns, if the stored data already has the
correct bytes, is to cast the data to character set OCTETS and store that
directly into the character set-whatever column. But I don't see how it
would work for unicode, because the actual bytes in the character codes are
totally different.
Is there any special reason why you need to convert to the data to unicode
rather than ISO8859_2?
Other details you haven't mentioned include what the default character set
is for your database and whether you are setting your client connection's
lc_ctype param correctly for it (sorry, I don't know the Java class but
it's one of the "basics" for connection).
>What's a datapump tool? :)It's a tool that pumps data from one database to another. They vary in
>Do you know any free ones? :)
capability. There's a list in the Downloads > Contributed area at
www.ibphoenix.com, some free, some not.
If you are on Windows and you know your SQL well, the free IB_SQL tool at
www.ibobjects.com has a datapump that sets up a cross-database transaction
between the source and the target dbs. You set up the source (a SELECT
statement) and target (an INSERT or UPDATE statement) exactly as you want
them. You can map the source fields to the target fields
individually. When you run the pump, the output from the source is
streamed directly to the target. It's a two-phase commit, so if something
falls over, the whole lot will fail and can be rolled back. Using that
tool, I'd first try a simple select on the source side and cast the input
on the target side.
HB