On 29/06/11 14:34, David Nicol wrote:
On Wed, Jun 29, 2011 at 3:02 AM, Martin J. Evans
<martin.ev...@easysoft.com> wrote:
BEGIN THING TO INSERT
=head3 On use of non-C<SELECT> SQL in C<select*_*> methods
When you really don't know if the statement you have in a
variable is going
to be a C<SELECT> or not, unrolling the process into
C<prepare>,C<execute>, and
a C<fetch*> called within an C<eval> block will work.
END THING TO INSERT
Unfortunately this does not hold true for DBD::ODBC:
How to emphasize "called within an C<eval> block" ???
perl -le 'use DBI; my $h = DBI->connect(); my $s = $h->prepare("create table
fred (a int)"); $s->execute; my $r = $s->fetch;'
DBD::ODBC::st fetch failed: no select statement currently executing
(SQL-HY000) at -e line 1.
Right, right! What happens when you put an C<eval> around the fetch?
perl -le 'use DBI; my $h = DBI->connect(); my $s = $h->prepare("create
table fred (a int)"); $s->execute; my $r = eval {$s->fetch};'
that is ok right now and no side effects in DBD::ODBC.
That is, are there any drivers where calling a bogus fetch WITHIN AN
EVAL BLOCK has any side effects? Error counters that max out, or
anything like that?
Don't know however, I am inclined to change the error to a warning as Tim
suggested. It simplifies things for people who might be calling fetch on a
non-select. However, it isn't going to happen soon unless someone screams for
it.
I was hoping DBI would define the behaviour but it seems that might be too
difficult.
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
