MySQL Forums
Forum List  »  Connector/ODBC

MySQL ODBC 8.0 Unicode Driver and utf8
Posted by: Phil Loats
Date: August 16, 2021 03:59PM

We have recently added MySQL support to our application utilizing the MySQL ODBC 8.0 Unicode Driver and we have encountered problems reading utf8 data from the database. I expect we need an additional configuration, but I have not found such. I'm hoping better experience can assist me.

We are using RHEL8 and using mysql-connector-odbc-8.0.26.1.el8,
We have configured and confirmed using the /usr/lib64/libmyodbc8w.so library,
The database schema reports being utf8mb4,
The table shows using utf8mb4,
The column shows using utf8mb4.

Using isql for testing with libmyodbc8w.so gives the exact same results as our application.

I can confirm the data in the specific column is encoded as utf8 (so the storage part is working correctly), e.g. SELECT hex(CN) from <table>; will report
\x55\x73\x65\x72\x31\x20\xC5\xA0\x76\x61\xC4\x8D (User1 Švač)

When using mysql application, SELECT CN from <table>; returns the correct utf-8 string. It appears the mysql application does not use the ODBC driver library.

When using isql with the MySQL Unicode Connector ODBC we get a string like "User1 ?va?".

The default for character_set_results reports as unset. "set character_set_results=utf8mb4" still shows the wrong string. But interestingly, using "set character_set_result=binary" will show the correct utf8 string (maybe this is a workaround?).

I've sampled MySQL Connector ODBC versions 17, 21, 25, 26 with all the same results. Windows MySQL driver ODBC also has the same problem.

If I change isql to use mariadb-connector-odbc I get the correct results.

Can anyone offer any suggestions what I might be missing?

Options: ReplyQuote


Subject
Written By
Posted
MySQL ODBC 8.0 Unicode Driver and utf8
August 16, 2021 03:59PM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.