On Tue, May 10, 2011 at 08:01:02PM +0100, Martin J. Evans wrote: > > o returning the data in some native codepage like windows-1252 does > not help you really, it probably hinders you and in any case you can > encode it as windows-1252 afterwards when you output it somewhere. > > As a result, I think it was probably an omission when DBD::ODBC was > changed to support Unicode that it continued to retrieve varchar > columns as SQL_CHAR and it should retrieve them as SQL_WCHAR (so > long as the driver supports this - there is a SQLGetInfo call to > check). In this way the data retrieved to a Perl script should > always be accurate and can easily be translated to other charsets > and encodings if that is what you need. The hopefully slight > downside is that anyone running code with DBD::ODBC as it stands and > like the person who started this on rt, if they know the data was > coming back as windows-1252 (or whatever) and attempt to decode it, > they will get the wrong data as it is already unicode characters. > > I propose to change DBD::ODBC to always bind varchar etc columns as > SQL_WCHAR and hence get unicode data in the unicode build but add a > connection attribute to return it to the previous behaviour. I could > have done it the other way around but this default seems more > logical to me. > > If you have any comments before I make this change I'd be happy to > hear them.
Sounds good to me. Thanks. Tim.
