List:MySQL++« Previous MessageNext Message »
From:Charles J. Daniels Date:May 29 2013 1:12am
Subject:Re: accessing utf8, continued, update
View as plain text  
This page mentions the exact issue it seems:

http://forums.mysql.com/read.php?45,362257,362257

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", "127.0.0.1", "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
>

Thread
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