Re: Is it ever legal (should be supported) to issue a non select in selectall_arrayref?

On 24/06/11 16:17, David Nicol wrote:
> On Sat, Jun 11, 2011 at 12:51 PM, Tim Bunce<[email protected]>  wrote:
>> Patch welcome.
>>
>> Tim.
>
> here's a revised new paragraph, to go right before the  =head3 C<prepare>.
>
>
> BEGIN THING TO INSERT
> =head3 On use of non-C<SELECT>  SQL in C<select*_*>  methods
>
> While some drivers support statements other than C<SELECT>  in the above-listed
> convenience functions, others do not: driver support for this facility
> is not defined
> by the DBI interface standard, and the C<do>  method is provided for
> non-C<SELECT>
> statements. 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
> a C<fetch*>  called within an C<eval>  block will work.
> END THING TO INSERT

Unfortunately this does not hold true for DBD::ODBC:

perl -le 'use DBI; my $h = DBI->connect(); my $s = $h->prepare("create table fred (a int)"); $s->execute; my $r = $s->fetch;'
DBD::ODBC::st fetch failed: no select statement currently executing (SQL-HY000) at -e line 1.

Does this mean DBD::ODBC has a bug?

If so, and as I said before, I don't think DBD::ODBC knows the difference between a fetch called as part of selectall_* or a fetch called directly and the only way out would be to report no errors in fetch at all if the statement is not active.

AV *dbd_st_fetch(SV *sth, imp_sth_t *imp_sth)
{
     D_imp_dbh_from_sth;
     D_imp_xxh(sth);
     int i;
     AV *av;
     RETCODE rc;
     int num_fields;
#ifdef TIMESTAMP_STRUCT /* iODBC doesn't define this */
     char cvbuf[512];
#endif
     int ChopBlanks;

     /* Check that execute() was executed sucessfully. This also implies	*/
     /* that dbd_describe() executed sucessfuly so the memory buffers	*/
     /* are allocated and bound.						*/
     if ( !DBIc_ACTIVE(imp_sth) ) {
         dbd_error(sth, DBDODBC_INTERNAL_ERROR, "no select statement currently executing");
         return Nullav;
     }
>
>
>
> the alternate of calling the select_*_ in the eval, then falling back
> to the do, is not suggested,
> as it might cause the SQL to get done twice. I think explicitly warning against
>
>
>     my $ar;
>     eval { $ar = $dbh->  selectall_arrayref($SQL); 1} or $dbh->do{$SQL);
>
>
>   would be going too far.

Martin
-- 
Martin J. Evans
Easysoft Limited
http://www.easysoft.com