FreeTDS Development Group

[Chuck Bearden <cfbearden AT gmail.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.

> AIUI, there's some issue with iconv and parameter passing.  Or was.  There
> was a thread on the subject recently.  I don't see anything in ChangeLog.
> 
> Please try with inline code to confirm that's the issue.  Perhaps Frediano
> will be able to shed some more light.
> 
> > My only interest in UCS-2 was due to the hope that, if the server
> > likes UCS-2, I could bypass conversion issues by feeding it UCS-2.  If
> > I can make the loading work with UTF-8 I'll be perfectly happy.
> 
> We made it pretty hard to bypass.  Conversion is done in libtds near the
> wire-handling code; the server's encoding has a short lifetime on the
> client side.
> 
> One workaround for now might be to bcp the data into a staging table, and
> call your stored procedure once per row.  That should at least work.

I have never used bcp.  Let me look into it.

Thanks again,
Chuck