Skip Menu |
 

This queue is for tickets about the DBD-ODBC CPAN distribution.

Report information
The Basics
Id: 75693
Status: resolved
Priority: 0/
Queue: DBD-ODBC

People
Owner: Nobody in particular
Requestors: Wayne.Bower [...] lsi.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 1.35



Subject: DBD::ODBC::st fetchrow_array failed: no select statement currently executing (SQL-HY000)
Date: Sun, 11 Mar 2012 11:07:03 -0400
To: "bug-DBD-ODBC [...] rt.cpan.org" <bug-DBD-ODBC [...] rt.cpan.org>
From: "Bower, Wayne (Wayne)" <Wayne.Bower [...] lsi.com>
Download (untitled) / with headers
text/plain 1.2k
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
Download fetch_no_select.log
application/octet-stream 3.1k

Message body not shown because it is not plain text.

Download fetch_no_select_dbi.log
application/octet-stream 24.2k

Message body not shown because it is not plain text.

Download fetch_no_select.pl
text/x-perl 2.1k

Message body is not shown because sender requested not to inline it.

Download (untitled) / with headers
text/plain 3.3k
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
Subject: RE: [rt.cpan.org #75693] DBD::ODBC::st fetchrow_array failed: no select statement currently executing (SQL-HY000)
Date: Wed, 14 Mar 2012 11:39:17 -0400
To: "bug-DBD-ODBC [...] rt.cpan.org" <bug-DBD-ODBC [...] rt.cpan.org>
From: "Bower, Wayne (Wayne)" <Wayne.Bower [...] lsi.com>
Download (untitled) / with headers
text/plain 2.2k
<URL: https://rt.cpan.org/Ticket/Display.html?id=75693 > On Mon Mar 12 15:28:11 2012, Martin J Evans via RT bug-DBD-ODBC@rt.cpan.org wrote: Show quoted text
> 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.
Downloaded and installed 1.35 and works great so far. Thank you, Wayne Bower


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.