Thanks for the quick answer!
There's something I just don't understand:
If I display the hungarian chars from the source DB for example in a
JTextField, the characters display correctly
If I type in the same chars in another TextField and insert them in
the new database, I guess this error won't happen (haven't tried it
out yet, but that would be distressing if it wouldn't work....)
So this means a String in java can be different from another String
with absolutely the same content? (i cannot insert the first because
of transliterate error, but I can insert the second)
Brrrrrr....
Is there no way to convert the "bad" String into a "good" String in
java? Without losing data?
Like j=new JTextField(badstring)
insert(j.getText()) ? :)

Or can the DriverManager.getConnection(url,properties)
help me if I set something in properties?

Thank you!
John

--- In Firebird-Java@yahoogroups.com, Helen Borrie <helebor@t...> wrote:
> At 09:18 PM 11/01/2004 +0000, you wrote:
> >Hello!
> >Firebird 1.03.972, JayBird 1.0.1
> >I want to transfer all data from database1 to database2(UNICODE_FSS)
> >to a different structure
> >I use JDBC
> >String totransfer=olddatabaseresultset.getString(x)
> >and if totransfer has say a '�' character and I want to
> >newdatabasestatement.executeUpdate("insert into data(text)
> >values('"+totransfer+"')");
> >throws a FBSQLException: GDS Exception ...... Cannot transliterate
> >character between character sets
> >
> >Now what's the workaround, how can I insert chars like "��ő
�ű���"=
> >
> > into
> >my new database?
>
> This isn't simple. You have to resolve your source dataset so that the
> character columns are cast to the correct character set.
>
> select
> cast(charcol1 as varchar(40) character set unicode_fss) as
charcol1_u,
> datecol,
> ....
>
> There are a lot of gotchas with this character set conversion, e.g.
index
> size limits (253 bytes = 84 characters or less), text blobs that
can't be
> converted, etc.
>
> If this is a one-off operation, an existing datapump tool might be your
> best bet.
>
> Helen