FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

Steve Langasek wrote:
> > I think I recognize Steve's patch?  
> 
> Yeah, this is the Bad version of the patch that shipped in sarge as
> well. :/ The only chance to fix this for Dapper is probably to ask the
> Ubuntu maintainer to pull the patch, since the freeze for Dapper is upon
> us; for etch and for Dapper+1 I'd like to see freetds 0.64 released with
> the fixed version of the locale patch that I proposed on the list.

Steve, 

Thanks for weighing in.  I think I'm slowly getting it.  

You and Frediano both suggest applying your patch to 0.64.  I think you've
both thought about this more carefully than I have, and I respect your
judgement.  You wouldn't suggest applying a patch at this stage of the
game unless you were sure it's an improvement.  

I'll apply it and post 0.64rc3.  If there's something more that needs
doing, tell me.  

I'll look again at the patch, of course, but let me restate my
understanding of your intent:

1.  Absent an override, use nl_langinfo(3) to determine the client
charset. 
2.  The environment settings are overridden by 'client charset' in
freetds.conf. 
3.  nl_langinfo() is not available and 'client charset' is absent,
locales.conf will be used to infer a client character set.  
4.  Charset information is used both by iconv and in the TDS 5.0 login.  

> I'll talk to Adam Conrad and see if we can get this fixed up yet for
> Dapper.

As you see fit.  I can see advantages both ways.  The situation AIUI is
that the Sybase server is initially asked to use a character set it
doesn't suppport.  It feeds that back to the client in a message, and
FreeTDS responds accordingly.  The only problem is that it can't be
overridden, and causes log messages to accumulate on the server.  

I would find it very helpful if you'd let us know what patch, if any, you
include in your releases.  Certainly it would have shortened this thread. 
:-)

Regards, 

--jkl