Bug #75693 for DBD-ODBC: DBD::ODBC::st fetchrow_array failed: no select statement currently executing (SQL-HY000)

> While testing our code with DBD::ODBC 1.33 I found a case that is > failing. > > The 1st attachment (fetch_no_select.pl) is the script that > demonstrates the problem. > > And the 2nd attachment (fetch_no_select.log) is from > DBI_TRACE=15=fetch_no_select_dbi.log ./fetch_no_select.pl > > And the 3rd attachment (fetch_no_select_dbi.log) is the DBI_TRACE > output. > > This is using perl 5.14.1, DBI 1.616, DBD::ODBC 1.33 with freeTDS 0.91 > and unixODBC on Linux. > > The script creates a procedure and executes it resulting in the > following error: > DBD::ODBC::st fetchrow_array failed: no select statement currently > executing (SQL-HY000) > > Essentially the issue occurs if the dbi code attempts to fetch data > and the procedure is not selecting anything. Keep in mind that > this is just a test case to reveal the issue. Our actual procedure > has more complex conditions which determine whether there is > anything to select. > > The error occurs using DBD::ODBC 1.33 with freeTDS 0.91, but doesn't > occur using our older installation of DBD::ODBC 1.16 with freeTDS > 0.64. > > The prior handling seems correct to me. I.e. fetchrow_array returned > an empty list instead of throwing an error. > > Please let me know if more information is needed. > > Thank you, > Wayne Bower >

> It does the same thing on Windows: > > Create TMP_SP_Test_ODBC that conditionally runs SELECT > exec TMP_SP_Test_ODBC that conditionally runs SELECT > Fetched from TMP_SP_Test_ODBC: > DBD::ODBC::st fetchrow_array warning: no select statement currently > executing at > rt_75693.pl line 89. > TMP_SP_Test_ODBC rv=<0> > Drop TMP_SP_Test_ODBC > > I have a recollection this changed in a later DBD::ODBC. > > =head2 Changes in DBD::ODBC 1.30_7 June 15, 2011 > > [BUG FIXES] > > Some time ago (I don't know when) a few internal errors generated by > DBD::ODBC got ignored. There are about 5 of them but I seriously > doubt anyone would hit any other than the data truncated error > (which is reported by the ODBC driver anyway) and "no select > statement currently executing". You can see rt_68720.t in the t > directory for an example of the latter. > > then later: > > =head2 Changes in DBD::ODBC 1.34_5 February 17 2012 > > [BUG FIXES] > > * The 40UnicodeRoundTrip tests counts could be 1 off in some cases. > > * Fix for t/03batt.t which could fail a test if the data source had > no table - Kenichi Ishigaki > > * If a driver misbehaves during global destruction e.g. SQLFreeStmt > fails but no error is available DBD::ODBC issues an error saying > an error occurred but no error diagnostics could be found. This is > pointless and irritating during global destruction. This stems > from a change in 1.28. Thanks to Peter Rabbitson for reporting > and suggested fix. > > [CHANGE IN BEHAVIOUR] > > * Prior to this release if you called selectall_* methods with a > non-select statement DBD::ODBC would raise an error saying "no > select statement currently executing". See RT 68720. After > discussions on dbi-dev the concensus seems to be that issuing a > warning in this case is better so that is what I've done. As a > result t/rt_68720.t has been removed and > t/85_selectall_non_select.t has been added. > > Try 1.35.