Re: Database with different character set problems

hi, thanks for your reply.

> Sounds too daft to be true, but could it be:
> - testing1 queries testing2 table: varcahr2(10 BYTE).
> - testing1 retrieves all from the column: all 10 bytes
> - as testing1 is in UTF8 mode, 3 characters (and a bit)
> fill up the 10 BYTES, as they get retrieved as 3-byte
> characters.
> Should not happen. Sounds like a major bug.

   yes.

>
> Test it with a different character set setting
> on the testing1 side. Remeber, testing1 is client
> as well as server: if you just use sql on the testing1
> sode, you should see the same behaviour (connect to
> testing2, as do a select * from testing_chinese; )

  when i query in testing2, all characters can be seen (with select * from testing_chinese)

> I cannot reproduce this behaviour with a single-byte
> client, an AL32UTF8 (9.2) database and double byte
> characters.
> But you already said so. Your problem was with 8i.

  if query in another 9i database, character set is UTF8, all characters can be seen (with select * from testing_chinese_at_testing2)

> I think your only solution is to upgrade the 8i, as
> 8i is desupported by the end of this year. I do
> not think Oracle will solve such a problem in 8i
> when it does not occur in 9i
>
> Having said all that, and rereading, I begin to doubt
> the cause and action here: you talk alot about
> database versions. Are you just retrieving them, or
> storing as well?

  testing1: UTF8, version 8.1.7, only three characters can be seen (with select * from testing_chinese_at_testing2)
  testing2: ZHT16BIG5, version 8.1.7, one table has only one column, varchar2(10), all characters can be seen (with select * from testing_chinese)

  9i database: UTF8, all characters can be seen (with select * from testing_chinese_at_testing2)

  I don't know whether there ara some setting that I should set. For 8i, should it also display all characters in testing1? And what is the differences between UTF8 and AL32UTF8 in 9i?

> If you store them in another characterset database,
> it all makes sens - and I'll go back to the first
> reaction: define your table with: varchar2(10 CHAR),
> and it will work
>
> --
>
> Regards,
> Frank van Bortel
Received on Sat Feb 14 2004 - 23:58:45 CST