Günther Schmidt wrote:

Am 04.05.2009 um 21:07 schrieb John Goerzen:

...

Günther Schmidt wrote:

...

Hi John,

I'm afraid so.

If it came back as an SqlString "G\252nni" then it propably wouldn't be a problem. Can you boil this down to a few-line self-contained test program so I can try it myself? I do have test cases for Unicode stuff and they are all passing here. I would like to be able to eliminate your environment as a culprit.

I'll try, it will take me some time since I've never written a test in haskell.

You don't really have to make a special unit test. Just a simple client program that creates a table, inserts some data, reads it back, and demonstrates the corruption.

That'll be harder to do since I'm on XP here, but I'll try that too,

No problem. It's just runghc setup configure -f buildtests runghc setup build and just run runtests

...

...

Am 04.05.2009 um 20:47 schrieb John Goerzen:

...

Günther Schmidt wrote:

...

Hi John,

what I just noticed is that *all* strings come back as SqlByteStrings. That's normal, and pretty much irrelevant, since fromSql takes care of it.

It's documented, even: the SqlByteString is assumed to be in UTF-8, and is decoded when converted to a String.

It is not correct to have \252 in the SqlByteString. The proper sequence there is \xc3\xbc. When converted to String, *then* it should be \252.

Are you positive you're seeing \252 in the SqlByteString? That doesn't make any sense to me. It's not a valid UTF-8 encoding.

How have Umlauts been behaving on your end? Were they as mean to you as they were to me?

...

...

ie. I get my "Günni", (G\252nni), back as an SqlByteString "G \252nni" instead of an SqlString "G\252nni".

So when I cast, ie. fromSql x :: String, I get an "G\65533nni", which is where the garbling occurs.

BTW this is the 3rd time now that I'm writing the same bloody email, my email client "clipped" the previous 2.

Günther