Re: error for insert into varbinary column: Implicit conversion from data type varchar to varbinary is not allowed
Frediano Ziglio <[email protected]>
| Newsgroups | gmane.comp.db.tds.freetds |
|---|---|
| Message-ID | <[email protected]> |
2010/3/2 Hari Krishna Dara <[email protected]>: >> Date: Sun, 28 Feb 2010 15:06:01 +0100 >> From: Frediano Ziglio <[email protected]> >> Subject: Re: [freetds] error for insert into varbinary column: >> Implicit conversion from data type varchar to varbinary is not allowed >> To: FreeTDS Development Group <[email protected]> >> Message-ID: <[email protected]> >> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes >> >> Il giorno 26/feb/2010, alle ore 19.52, Hari Krishna Dara <[email protected] >> > 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). freddy77 _______________________________________________ FreeTDS mailing list [email protected] http://lists.ibiblio.org/mailman/listinfo/freetds