Re: Is it ever legal (should be supported) to issue a non select in selectall_arrayref?

On 29/06/11 14:34, David Nicol wrote:
> On Wed, Jun 29, 2011 at 3:02 AM, Martin J. Evans
> <[email protected]>  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