Skip to Content.
Sympa Menu

freetds - Re: [freetds] error for insert into varbinary column: Implicit conversion from data type varchar to varbinary is not allowed

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Hari Krishna Dara <haridara AT gmail.com>
  • To: freetds AT lists.ibiblio.org
  • Subject: Re: [freetds] error for insert into varbinary column: Implicit conversion from data type varchar to varbinary is not allowed
  • Date: Mon, 1 Mar 2010 19:53:29 -0800

> Date: Sun, 28 Feb 2010 15:06:01 +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: <6169E80E-6CF2-447F-8018-20E0E9817064 AT gmail.com>
> Content-Type: text/plain;       charset=us-ascii;       format=flowed;  
> delsp=yes
>
> Il giorno 26/feb/2010, alle ore 19.52, Hari Krishna Dara <haridara AT gmail.com
>  > ha scritto:
>
> >>
> >> 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

Is there an existing issue to track this, or should I log a new one
(in which case, what should the description really say?)?

--
Thanks,
Hari




Archive powered by MHonArc 2.6.24.

Top of Page