FreeTDS Development Group

[Steve Langasek <vorlon AT dodds.net>]

On Sat, Oct 15, 2011 at 01:59:07PM -0300, Nelson A. de Oliveira wrote:
> On Sat, Oct 15, 2011 at 1:00 AM, Casey Boardman
> <cboardman AT batterymarch.com> wrote:
> > I *think* that the client charset needs to match what the server is
> > sending.   So if the server is sending CP850, you need to set freetds to
> > expect that, or things will get garbled.   Did you try that?   What was
> > the result?

> Hmm... indeed.
> Making "client charset = CP850" did the trick.

How did FreeTDS end up with such awful semantics for 'client charset'?  Why
should 'client charset' be interpreted as meaning "the charset the server
uses for encoding data"?

And correct me if I'm wrong, but my understanding is that the TDS protocol
already includes sufficient information ("collation" value on columns) for
this to be entirely autodetected.  Why should FreeTDS ever need to be
configured for this at all?  The character set as returned by the library to
the client should default to the locale charset; the character set used on
the wire should be the appropriate one for the column as determined by
negotiation with the server; the library should automatically convert
between these two charsets as needed; and users should only ever need to
override the charset in the rare case that they want to use a different
character set on *their* side of the interface (i.e., because the consumer
wants the data in a format other than the one suggested by the locale).

Why do we seem to be so far away from this ideal?  I can't understand why
tsql or sqsh should ever give me garbage characters as output.

And I'd like to help see it fixed, but I'm having a hard time understanding
how we got to this point in the first place, so I must be missing something.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek AT ubuntu.com                                     vorlon AT debian.org