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

Frediano Ziglio freddy77 at gmail.com
Tue Mar 2 04:26:07 EST 2010

2010/3/2 Hari Krishna Dara <haridara at gmail.com>:
>> 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?)?

You can open a bug/feature request at
http://sourceforge.net/projects/freetds/, not readed very frequently
but is a good place to keep it persistent. I'm working on the issue.
There are some functions that need to fetch results set in order to
make it works correctly. This will lead also to a performance improve
using TDS 7.1+ (from mssql 2000).


More information about the FreeTDS mailing list