FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

Il giorno 26/feb/2010, alle ore 19.52, Hari Krishna Dara <haridara AT gmail.com 
> ha scritto:

> > Date: Fri, 26 Feb 2010 15:30:05 +0100
> > From: Frediano Ziglio <freddy77 AT gmail.com>
> > Subject: Re: [freetds] error for insert into varbinary column:
> >       Implicit        conversion from data type varchar to  
> > varbinary is
> > not allowed
> > To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
> > Message-ID:
> >       <aa1b71111002260630p3904d213jffd79fabbd1b975d AT mail.gmail.com>
> > Content-Type: text/plain; charset=UTF-8
> > > Since I am using pyodbc.Buffer (which itself is mapped to python's
> > built-in
> > > buffer type), this is not text. If somewhere in the stack, it is  
> > > being
> > > treated as text, then it is a bug.
> > >
> > > -- Hari
> >
> > To narrow down the problem a DM log would help. If program bind
> > pyodbc.Binary type to text this is a problem in pyodbc.
> >
> > Regards
> > Frediano
> >
> > I doubt it is a pyodbc binding problem since the same code works with
> easysoft driver and all drivers on windows.  Besides, it is not even
> reaching the bind stage yet, it fails right at the prepare. I have  
> tracing
> enabled for pyodbc and I can confirm that it fails in the prepare  
> and bind
> is not called yet. Also, when running in debug versions of python,  
> pyodbc,
> unixodbc and freetds the breakpoint is never reached when set in
> SQLBindParameter. I can also confirm this from the DM log. I am  
> attaching
> the log generated while using freetds as well as easysoft, so you  
> can see
> the difference (it will help you open them side by side by using  
> tool such
> as vim diff). I am also attaching the freetds dump file in case it  
> helps.
>
> --
> Thank you,
> Hari

I think that under Windows and easysoft driver it works cause they  
prepare on first execute when parameters are already binded. I tried  
to enable the same behaviour (setting need_reprepare and returning  
SQLSUCCESS from SQLPrepare) but prepare_results test fails so I think  
that some additional code is required to allow better IRD handling.

Bye
   freddy77