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 <martin.ev...@easysoft.com
> ><mailto:martin.ev...@easysoft.com>> 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
> >
> >
>
