On Sun Mar 11 11:07:16 2012, Wayne.Bower@lsi.com wrote:
Show quoted text> 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
> >fetch_no_select.log 2>&1
>
> 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.
Martin
--
Martin J. Evans
Wetherby, UK
