FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> 
> 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.

freddy77