On Tue, Sep 10, 2002 at 01:49:35PM +0200, Roger Perttu wrote:
> Tim Bunce wrote:
> >On Wed, Sep 04, 2002 at 09:58:35AM -0500, Paul DuBois wrote:
> >
> >>At 9:50 -0500 9/4/02, David Dooling wrote:
> >>
> >>>For security reasons, wouldn't you want to know what statements are
> >>>non-select _before_ you execute?
> >>>
> >>>If you only care about after, how about something like this:
> >>>
> >>> $sth->execute;
> >>> my @row = $sth->fetchrow_array;
> >>> if (@row) { # results }
> >>> elsif (!$sth->errstr) { # now rows }
> >>> else { warn $sth->errstr }
> >>>
> >>>You can't distinguish between selects that return no data and
> >>>non-selects. But for your example below, it really wouldn't matter.
> >>>It seems you need to parse this stuff before.
> >>>
> >>In MySQL, you can distinguish select from non-select statements after
> >>$sth->execute by checking $sth->{NUM_OF_FIELDS}. If it's zero, it's
> >>a non-select, if it's non-zero, it's a select. This works even if the
> >>select returns zero rows, because the "width" of the result set is
> >>greater than zero. No parsing of the statement or any other messing
> >>around with it is necessary.
> >>
> >>Does this work for other database engines as well?
> >
> >It has to as it's the "standard" way to check. The DBI docs specifically
> >say "Non-C<SELECT> statements will have C<NUM_OF_FIELDS == 0>."
> >
> >Tim.
> The pod is a bit unclear about NUM_OF_FIELDS. I know that it returns
> something > 0 for stored procedures containing select-statements. But I
> know this by testing not by reading the pod.
That's very database/driver-specific (Sybase and MSSQL only as far
as I know) and the whole issue of how such cases should be handled
by the DBI is currently mostly undefined.
All add a mention of the issue to the docs. Thanks.
Tim.
