Hi everyone,
I have a problem with DBI. If I have no control of the SQL statement
being run, how do I know if it's safe to call fetchrow_hashref()?
my $sth = $dbh->prepare($someUnknownStatement);
$sth->execute();
# Safe to call fetchrow_hashref()?
I know I can turn of RasieError and PrintError but I want to catch
_real_ errors. I could also use eval but should I then search the error
string for "no select statement currently executing" and ignore the
error if I find it. That would be very ugly code. Surely there must be a
better way. I don't understand why fetchrow_hashref() just doesn't
return undef.
Thanks,
Roger Perttu
-------- Original Message --------
Subject: RE: ODBC 0.45 test Was: [Re: :ODBC 0.45 beta better than 0.41?
(With attachments)]
Date: Tue, 3 Sep 2002 13:23:22 -0400
From: Jeff Urlwin <[EMAIL PROTECTED]>
To: Roger Perttu <[EMAIL PROTECTED]>
CC: <[EMAIL PROTECTED]>
Roger,
Yes, I see that, but that's just the way DBI works. If you have a
non-select statement, fetchXXXX will not work and will produce an error.
Regards,
Jeff
>
> Jeff Urlwin wrote:
>
> <stuff cut>
>
> > Roger Perttu wrote:
>
> >>It's mostly got to do with the fact that I don't like the behaviour of
> >> fetchrow_hashref. I don't consider it an error or warning if I call
> >>fetchrow_hashref without an open result set. If there is no data, fine,
> >>return undef. Since fetchrow_hashref is throwing errors at me I need
> >>something to wrap my fetch loop inside. (Yes I know I can mess with
> >>$sth->{RaiseError} but it's ugly)
> >>
> >>
> >
> >You shouldn't get an error, unless you try to fetch more than once. The
> >error's there because a number of people forget execute(), then call
> >fetchrow_hashref() blindly getting nothing. The first time calling
> >fetchxxxx with no data should not return an error, just an end
> of data set.
> >Subsequent calls do produce the error, though. Can you provide
> an example
> >of where it's not working?
> >
> >
> No it's not working for me.
> This code:
>
> sub test()
> {
> my $dbh = newDbh();
> my $sth = $dbh->prepare('create table Upgrade_Users (oldID int NOT
> NULL, newID int NOT NULL)');
>
> my $rowRef;
> $sth->execute();
> $rowRef = $sth->fetchrow_hashref('NAME'); # line 50
> $rowRef = $sth->fetchrow_hashref('NAME'); # line 51
> die "test";
> }
>
> will print this:
>
> E:\Projekt\Helpdesk\Perl\UpgradeDB>dbitest3.pl
> DBD::ODBC::st fetchrow_hashref failed: (DBD: no select statement
> currently execu
> ting err=-1) [for statement ``create table Upgrade_Users (oldID int NOT
> NULL, ne
> wID int NOT NULL)'' with params: ]) at
> E:\Projekt\Helpdesk\Perl\UpgradeDB\DbiTes
> t3.pl line 50.
> DBD::ODBC::st fetchrow_hashref failed: (DBD: no select statement
> currently execu
> ting err=-1) [for statement ``create table Upgrade_Users (oldID int NOT
> NULL, ne
> wID int NOT NULL)'' with params: ]) at
> E:\Projekt\Helpdesk\Perl\UpgradeDB\DbiTes
> t3.pl line 51.
> test at E:\Projekt\Helpdesk\Perl\UpgradeDB\DbiTest3.pl line 52.
>
> I shouldn't get printouts at both line 51 and 52.
>
> I'm now running with DBD::ODBC version 0.45_16. I haven't found any new
> bugs.
>
> Regards,
>
> Roger P
>
