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]> |
Il giorno 26/feb/2010, alle ore 19.52, Hari Krishna Dara <[email protected] > ha scritto: >> >> Date: Fri, 26 Feb 2010 15:30:05 +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=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