On Fri, Jun 17, 2011 at 04:11, David Nicol <davidn...@cpan.org> 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 > <martin.ev...@easysoft.com> 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 <jonathan.leff...@gmail.com> #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."