List:MySQL++« Previous MessageNext Message »
From:Charles J. Daniels Date:May 29 2013 1:33am
Subject:Re: accessing utf8, continued, update
View as plain text  
This issue is not fully resolved for me in terms of it now works, and below
is how. However, I'm at a loss as to why I have to specify an option to get
the default behavior, since default means if you don't say otherwise, ya
know? I'm not saying this is a mysql++ issue, as it seems to be determined
for you and not by you. I didn't know any better, and mysql++ docs state:

3.14. Connection Options

MySQL has a large number of options that control how it makes the
connection to the database server, and how that connection behaves. The
defaults are sufficient for most programs, so only one of the MySQL++
example programs make any connection option changes. Here is

You may want to change the docs, since I doubt the docs intended to imply
that receiving latin-1 was sufficient for most programs. While perhaps a
literally accurate statement, utf8 in modern days is bound to be anything
but rare.

Here's how I got it working:

mysqlpp::Connection conn;
SetCharsetNameOption* scno = new SetCharsetNameOption("utf8");
conn.connect("learning-with-texts", "", "root", "", 0);

Simple, and I get the results I expect.

Thank you everyone who sent me comments, or read my issue. I'll remain
subscribed to the list, since I love db issues.


On Tue, May 28, 2013 at 6:12 PM, Charles J. Daniels <chajadan@stripped>wrote:

> This page mentions the exact issue it seems:
> I currently believe this behavior is not mysql++ specific, however, it
> also seems to be that mysql++ will either forcibly (cannot help but) expose
> this issue, or it's a change in a new version of mysql that mysql++ should
> incorporate. I still note that TinyODBC seems to be sidestepping this issue
> without my assistance.
> --charlie
> On Tue, May 28, 2013 at 5:53 PM, Charles J. Daniels <chajadan@stripped>wrote:
>> Well I think I have it narrowed way down. When I call conn.driver() and
>> then get_options() on the driver, charset of this struct yields "latin1". I
>> don't know where this value comes from, or why it's that way, but for all I
>> know mysql++ sets it that way when connecting, though this seems unlikely
>> by your stance. But maybe I have like, no mysql drivers installed except
>> one that only works in latin1. So the value is stored utf8, mysql passes it
>> out utf8, the driver converts to latin-1, mysql++ gets and passes on that
>> latin-1, hence I lose data. How does mysql++ choose which driver it will
>> connect through? My connection string
>> is: conn.connect("learning-with-texts", "", "root", "", 0); and I
>> create the conn object with a default constructor. conn.client_version()
>> returns 5.5.27, in case that's pertinent. I find it hard to imagine a
>> driver would default to an encoding so heavily it would be the single
>> determining factor, without a request.
>> So, I see utf8 everywhere, the table create, the server variables, and
>> this one lone latin1 response as indicated. Does that shine light on this
>> all?
>> --charlie

accessing utf8, continued, updateCharles J. Daniels28 May
  • Re: accessing utf8, continued, updateWarren Young28 May
    • Re: accessing utf8, continued, updateCharles J. Daniels29 May
      • Re: accessing utf8, continued, updateCharles J. Daniels29 May
        • Re: accessing utf8, continued, updateCharles J. Daniels29 May