On Fri, Jun 17, 2011 at 04:11, David Nicol <[email protected]> wrote:
> Thanks-- the proposed docpatch was a trial balloon to get this answer.
> Here's copy for a revised proposed patch:
>
> 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 some C<fetch> variant called within an C<eval> block will always work.
>
Doesn't $sth->{NUM_OF_FIELDS} tell you whether the statement is something
that returns values or not? It's zero for anything that isn't similar to a
SELECT, and positive for any statement like a SELECT (or, for at least some
DBMS, things like EXECUTE PROCEDURE where the procedure returns values)?
The only thing I'm not sure about is whether $sth->{NUM_OF_FIELDS} is always
set by $dbh->prepare, or whether some DBMS can't set it until you do
$sth->execute.
> On Fri, Jun 17, 2011 at 2:51 AM, Martin J. Evans
> <[email protected]> wrote:
> >
> > So the proposed change saying
> >
> > "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 some C<fetch> variant will always work, as C<fetch> is defined to
> > return no data when called on executed non-C<SELECT> statement handles."
> >
> > I don't see how DBD::ODBC is supposed to implement that. fetch is just an
> > alias for fetchrow_arrayref. There is fetch and nothing else. If you call
> > selectall* it ends up in dbd_st_fetch, if you call fetch it ends up in
> > dbd_st_fetch.
> >
> > So the question becomes which is right DBD::Sybase behaviour or
> DBD::ODBC.
> >
> > Martin
>
--
Jonathan Leffler <[email protected]> #include <disclaimer.h>
Guardian of DBD::Informix - v2011.0612 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to be
amused."
