Skip to Content.
Sympa Menu

freetds - Re: [freetds] Character conversion issues

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Chuck Bearden <cfbearden AT gmail.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Character conversion issues
  • Date: Fri, 29 Oct 2004 13:32:25 -0500

On Fri, 29 Oct 2004 10:07:50 +0200, ZIGLIO, Frediano, VF-IT
<frediano.ziglio AT vodafone.com> wrote:
>
> >
> > On Thu, 28 Oct 2004 23:40:52 -0400, James K. Lowden
> > <jklowden AT schemamania.org> wrote:
> > > On Thu, 28 Oct 2004 22:12:59 -0500, Chuck Bearden
> > <cfbearden AT gmail.com>
> > > wrote:
> > > > > > I can provide a TDSDUMP log of this if it would be helpful.
> > > > >
> > > > > You guessed it. ;-)
> > > >
> > > > Here it is:
> > > >
> > > > <http://acad24.sahs.uth.tmc.edu/tdslog/tdsdump.log.txt>
> > >
> > > Ach, du lieber. You didn't say you were passing UTF-8 as
> > parameters to a
> > > stored procedure. :-(
> >
> > Aber bitt' schön! I didn't realize I was. mx.ODBC must be invoking
> > stored procedures behind my back. All I do is call an '.execute()'
> > method on the mx.ODBC cursor with the SQL statement (placeholders for
> > values) and a tuple of values as the two arguments. The code is on
> > other machines, so I can't give you a sample at the moment.
> >
> > I'm guessing you are referring to 'sp_prepare' and
> > 'sp_unprepare'--those are the only stored procedures I can identify in
> > the trace log. I think that's how mx.ODBC prepares statements in a
> > reusable way. Perhaps there is some way around that.
> >
>
> mxODBC calls SQLPrepare, FreeTDS send a sp_prepare.
> I found a possible workaround. I don't know how to set attributes in
> Python however setting "encoding" attribute to "utf8" (or whateverm
> this it's a Python name, not a iconv or FreeTDS charset name) will
> translate unicode/8bit strings to utf-8 before binding to ODBC. If your
> default db encoding it's suitable for storing your characters this could
> work.

Thank you James & freddy77 for your responses. I have changed the
Python installation's default encoding from 'ascii' to 'utf-8', but
that did not help. It still chokes on the same name, a name which can
be decoded from UTF-8 into Python's internal Unicode representation,
but that cannot be encoded from Unicode into Latin-1. The client
charset is set to UTF-8 in freetds.conf. I'm guessing that FreeTDS is
still trying to turn the input into Latin-1/ISO 8859-1. Here is the
trace:

<http://acad24.sahs.uth.tmc.edu/tdslog/tdsdump.log.1.txt>

I think what I'll do for now is agree to lose some data by converting
all to Latin-1 with the 'replace' error mode and accepting that some
characters will be replaced by '?'.

Thanks again,
Chuck




Archive powered by MHonArc 2.6.24.

Top of Page