Re: Surprising DBD::Oracle error raised

[Martin J. Evans]

On 05/02/14 14:08, David Nicol wrote:

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.

So have I now and it made no difference.

And my SQL, which joins two tables, has
three placeholders, bound with bind_param between the "prepare_cached"
and the "execute."

Mine also use prepare_cached and a bind_param now - no change.

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.

Which is probably it.
Can you try updated versions so we can rule this out or alternatively, tell me 
what you are using and I'll try and reproduce it.

Martin