On Wed, Feb 5, 2014 at 7:25 AM, Martin J. Evans
<martin.ev...@easysoft.com> wrote:
>
> That is indeed interesting. When I run the following with DBD::ODBC to MS
> SQL Server:
>
> use strict;
> use warnings;
> use DBI;
>
> my $h = DBI->connect();
> eval {
> $h->do(q/drop table mje/);
> };
>
> $h->do(q/create table mje (a int)/);
> my $s = $h->prepare(q/insert into mje values(?)/);
> $s->execute(1);
> $s->execute(2);
>
> $s = $h->prepare(q/select a from mje where a = 1/);
> $s->execute;
> my ($row) = $s->fetchrow_array; # fetch result
> print "$row\n";
> $row = $s->fetch; # fetch status
> print "$row\n";
>
>
> I get:
>
> 1
> Use of uninitialized value $row in concatenation (.) or string at
> mje/fetch_off_end.pl line 20.
>
> However, I get the same with DBD::Oracle so how is you code different from
> the above.
>
> Martin
The code is the same. Rather, close enough, my second fetch was in
boolean context
while yours is in a storage context, but I don't think Perl cares,
both contexts are scalar.
And I've got RaiseError set. And my SQL, which joins two tables, has
three placeholders, bound with bind_param between the "prepare_cached"
and the "execute."
And your warning verifies that the second fetch returned an undef, as
documented, while mine threw an exception falsely claiming that the
statement hadn't been executed yet:
An Oracle error has occurred :
DBD::Oracle::st fetch failed: ERROR no statement executing (perhaps
you need to call execute first)
-------------------- SQL Text --------------------
select a from mje where a = 1
...
And you're certainly using more recent builds of everything.
--
The one L lama, he's a priest
The two L llama, he's a beast
And I will bet my silk pyjama
There isn't any three L lllama. -- Ogden Nash
