Re: DBD::ODBC Destroy bug?

On Wed, Apr 01, 2015 at 03:20:31PM +0100, Martin J. Evans wrote:
> 
> However, having said all that I didn't see you were using freeTDS
> until the last email. I've seen an issue with freeTDS returning and
> error status and then not supplying the reason before.
> 
> I have to say at this point I'm pointing a finger at your driver as
> whatever, if it returns SQL_ERROR from SQLFreeHandle it should tell us
> the error when we call SQLError. However, your ODBC log is strange as
> it does not show any SQLFreeHandle call failing (and it does not look
> long enough for what you do in your script).
> 
> The only bit I'm not too sure about (I doubt has anything to do with
> your problem) is that DBD::ODBC does the following at the end of
> dbd_st_destroy

>     if (imp_dbh->hdbc != SQL_NULL_HDBC && !PL_dirty) {
> 
>         rc = SQLFreeHandle(SQL_HANDLE_STMT, imp_sth->hstmt);
> 
>         if (DBIc_TRACE(imp_sth, DBD_TRACING, 0, 5))
>             TRACE1(imp_dbh, "    SQLFreeHandle(stmt)=%d\n", rc);
> 
>         if (!SQL_SUCCEEDED(rc)) {
>             dbd_error(sth, rc, "st_destroy/SQLFreeHandle(stmt)");
>             /* return 0; */
>         }
>     }
> 
>     DBIc_IMPSET_off(imp_sth);		/* let DBI know we've done it	*/
> 
> In this case, when no error can be found by dbd_error it does:
> 
>         DBIh_SET_ERR_CHAR(
>             h, imp_xxh, Nullch, 1,
>             "    Unable to fetch information about the error", "HY000", Nullch);
> 
> but of course then drops into DBIc_IMPSET_off(imp_sth) and returns which might not be ok. I don't know if Tim could comment on this.

DBIc_IMPSET_off is how the driver indicates that it's done all the
cleanup it can. The current code seems reasonable.

Tim.

> So, in summary, I cannot reproduce your error, I've seen freeTDS error and fail to tell us the error before, your code works flawlessly with the Easysoft and MS ODBC drivers and your ODBC log contradicts the DBI/DBD::ODBC log so I'm going to suggest you've updated or changed your freeTDS driver and this one is broken.
> 
> Martin
> 
> >
> >On Tue, Mar 31, 2015 at 4:23 AM, Martin J. Evans <[email protected] <mailto:[email protected]>> wrote:
> >
> >    On 31/03/15 06:04, Joel Plotkin wrote:
> >
> >        Hi,
> >
> >        I've attached the sample test8.pl <http://test8.pl> <http://test8.pl> script (smallest one possible that creates the problem) and a trace file at level 15.
> >
> >        Thanks for any insight,
> >
> >        Joel
> >
> >
> >         -dbd_st_execute(ac3cb0)=-1
> >         <- execute= -1 at test8.pl <http://test8.pl> line 74 via  at test8.pl <http://test8.pl> line 53
> >         -> DESTROY for DBD::ODBC::st (DBI::st=HASH(0xac3818)~INNER) thr#974010
> >         SQLFreeHandle(stmt)=-1
> >         !!dbd_error2(err_rc=-1, what=st_destroy/SQLFreeHandle(__stmt), handles=(c2abd0,c2b1c0,c802c0)
> >         ** No error found -1 **
> >         !! ERROR: 1 '    Unable to fetch information about the error' (err#1)
> >         <- DESTROY= undef at test8.pl <http://test8.pl> line 54 via  at test8.pl <http://test8.pl> line 54
> >         !! ERROR: 1 CLEARED by call to fetchall_arrayref method
> >
> >    This is suspicious - SQLFreeHandle failed and then the error was cleared.
> >
> >    I cannot reproduce and we need further clues.
> >
> >    Instead of starting tracing in the script could you rerun with DBI_TRACE=DBD=x.log
> >
> >    e.g.,
> >    set DBI_TRACE=DBD=x.log
> >    perl myscript.pl <http://myscript.pl>
> >
> >    This will put in the x.log file a load of ODBC info for the driver etc - could you send me the whole log file.
> >
> >    Another thing well worth doing is enabling tracing at the ODBC level as then we can try and find out why SQLFreeHandle is failing. You can do this by going to the ODBC administrator (make sure you pick the right one 32 bit or 64 bit depending on what your perl is) and selecting the tracing tab, enter a file and click on start then run your script.
> >
> >    Martin
> >
> >
>