On 24/06/11 16:17, David Nicol wrote:
On Sat, Jun 11, 2011 at 12:51 PM, Tim Bunce<tim.bu...@pobox.com>  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

Reply via email to