-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

robert kuzelj wrote:

> hallo mark,
>
>> Hopefully the following JUnit testcase helps show that your problem
>> doesn't exist at the JDBC level. It creates a UTF-8 connection to
>> MySQL-4.1.2, stores UTF-8 encoded strings directly and by prepared
>> statements, retrieves them, compares to original as strings, and
>> byte-for-byte using the UTF-8 encoding built in to the JVM.
> i really appreciate your efforts to help me. many thanks.
>
> nevertheless, i had such a junit-test allready and the only thing
> that it proves (imo) is that you can write something into the db
> and retrieve it with the same encoding again. this tells nothing
> about the transformation of strings from a java app to the jdbc
> driver and back or which encoding is used during that transform.

RobertJ,

If you specify UTF-8 as the characterEncoding connection property, then
that is the transform that is used from client -> server. The transform
that is used from server -> client is whatever character set the column
in the table is set to when you created the table (or conversely if you
use cast/convert in SQL to change it to some other character set).

> sorry for me being so resistant. but i tried now one additional
> client (SqlExplorer for intellij idea) and the result is again
> the same. if i execute my insert script via the shell
> [EMAIL PROTECTED]:> mysql < example_insert.sql or if i execute it with
> JFace (which then uses the connector/j jdbc driver) and if i
> check then in every single client...every single one displays
> the data as expected. if i write the data via my java-app all
> clients show garbage.
>
> maybe you understand that i am having a very hard time accepting
> that four client apps (SqlExplorer, JFace, mysqlcc, mysql-console)
> allways display the data correct if not written by my sample app and
> wrong if written by my app.
>
>
> of course it is possible that the other client-apps are misconfigured.
> but than again they must be wrongly configured in the exact same way
> as the results are very much the same. you must admit this is quite
> inprobable.

If you look at my previous e-mail, I _do_ show the command line client
retrieving your data just fine with UTF-8 data that was written into the
database by the _JDBC_ driver:

> And here's one from a unix x-term, which _does_ know about UTF-8:
> Welcome to the MySQL monitor.  Commands end with ; or \g.
> Your MySQL connection id is 153 to server version: 4.1.2-alpha-max-log
>
> - ----------------------------------------------------------------------
>
> Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
>
> mysql> select * from testUtf8;
> +--------+--------+
> | field1 | field2 |
> +--------+--------+
> | Käßsel | Böb    |
> | Käßsel | Böb    |
> +--------+--------+
> 2 rows in set (0.02 sec)


The only thing I can think of is there is something that is pertinent to
your problem that you are not showing with your code snippets that is
causing this issue. Would it be possible for you to post a _full_
testcase with your create table statements and such?

You might also try upgrading to a bk build of MySQL-4.1, only because
there have been charset changes in MySQL-4.1, and you're not using the
latest-and-greatest.

        -Mark


- --
Mr. Mark Matthews
MySQL AB, Software Development Manager, J2EE and Windows Platforms
Office: +1 708 332 0507
www.mysql.com

MySQL Guide to Lower TCO
http://www.mysql.com/it-resources/white-papers/tco.php
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAtSGytvXNTca6JD8RAjxoAKCPGQJ0hJa1VmZJZEwsbXOjDxq58wCfWHKk
1Bag2o23pJabTxKML92U4Mw=
=tk6+
-----END PGP SIGNATURE-----

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]

Reply via email to