Hi,
I think this issue can now be closed. Frediano Ziglio was able to add some
changes to the FreeTDS driver to fix the issues.
Here's the comments from applicable the Git changes (I think):
Allow to close cursors and prepared statement when connection is idle
Using ODBC is possible that closing a statement fails as connection
is now busy and is not possible to send requests to server.
Allow to post these close when connection goes to idle.
Just call tds_deferred_unprepare and tds_deferred_cursor_dealloc and
release cursor/dynamic.
Signed-off-by: Frediano Ziglio <fredd...@gmail.com>
This was committed to git on/around May 20, 2015.
(I believe this is the fix, if not, it is certainly fixed on/around
May 20, 2015.)
I've now re-tested the original test case with the latest "master" git
branch of FreeTDS and the issues/errors no longer persist.
Best,
Joel
On Wed, Apr 8, 2015 at 8:55 AM, Tim Bunce <tim.bu...@pobox.com> wrote:
> 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
> > >
> > >
> >
>
