Tim Bunce wrote:
>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.
>
>
>
I'm glad that I'm using MSSQL then!
I'm the one that started this thread and I'm _not_ interested in the
number of columns returned. All I want to do is to call fetch without
having the "no select statement currently executing" message thrown at
me. I get it the _first_ time I call fetch if it's a non
select-statement. I now know that I can catch the error using
HandleError but the code will be ugly. It would be much better if I
could disable this _unwanted_ help from DBI. All I want is undef unless
there is a serious error (syntax error, primary key violation etc).
Roger P
