On Thu, Feb 07, 2002 at 01:42:09PM +0100, Henrik Tougaard wrote: > > From: Tim Bunce [mailto:[EMAIL PROTECTED]] > > On Thu, Feb 07, 2002 at 11:13:22AM +0100, Steffen Goeldner wrote: > [...] > > > + sub sql_identifier_quote_char { > > > + my $dbh = shift; > > > + my $sth = $dbh->func('adSchemaDBInfoLiterals','OpenSchema'); > > > + while ( my $row = $sth->fetch ) { > > > + return $row->[1] if $row->[0] eq 'QUOTE'; # XXX > > > + } > > > + return undef; > > > + } > > > > Probably need a $sth->finish in there. > > No that is unneccessary! > > The DBI docs (version 1.201) state that $sth->finish "Indicates that no more > data will be fetched from this statement handle before it is either executed > again or destroyed." > The $sth will be destroyed during the 'return' processing, so a $sth->finish > should be quite superfluos here.
Ah, the docs aren't quite right because the destruction of a handle that's still 'Active' will trigger a warning. I've appended the diff to the docs. Let me know if you think it's not clear enough. Thanks. Tim. *** DBI.pm 2002/02/07 03:00:53 11.7 --- DBI.pm 2002/02/07 18:08:00 *************** *** 2976,2986 **** you disconnect, then you should explicitly call L</commit> or L</rollback> before disconnecting. ! If you disconnect from a database while you still have active statement ! handles, you will get a warning. The statement handles should either be ! cleared (destroyed) before disconnecting, or the C<finish> method ! should be called on ! each one. =item C<ping> --- 2976,2986 ---- you disconnect, then you should explicitly call L</commit> or L</rollback> before disconnecting. ! If you disconnect from a database while you still have active ! statement handles (e.g., SELECT statement handles that may have ! more data to fetch), you will get a warning. The warning may indicate ! that a fetch loop terminated early, perhaps due to an uncaught error. ! To avoid the warning call the C<finish> method on the active handles. =item C<ping> *************** *** 4181,4190 **** situations to allow the server to free up resources (such as sort buffers). ! When all the data has been fetched from a C<SELECT> statement, the driver ! should automatically call C<finish> for you. So you should I<not> normally ! need to call it explicitly. (Adding calls to C<finish> after each ! fetch loop is a common mistake, don't do it, it can mask other problems.) Consider a query like: --- 4181,4194 ---- situations to allow the server to free up resources (such as sort buffers). ! When all the data has been fetched from a C<SELECT> statement, the ! driver should automatically call C<finish> for you. So you should ! I<not> normally need to call it explicitly I<except> when you know ! that you've not fetched all the data from a statement handle. ! The most common example is when you only want to fetch one row, ! but in that case the C<selectrow_*> methods may be better anyway. ! Adding calls to C<finish> after each fetch loop is a common mistake, ! don't do it, it can mask genuine problems like uncaught fetch errors. Consider a query like: *************** *** 4203,4211 **** The C<finish> method does not affect the transaction status of the database connection. It has nothing to do with transactions. It's mostly an ! internal "housekeeping" method that is rarely needed. There's no need ! to call C<finish> if you're about to destroy or re-execute the statement ! handle. See also L</disconnect> and the L</Active> attribute. The C<finish> method should have been called C<cancel_select>. --- 4207,4214 ---- The C<finish> method does not affect the transaction status of the database connection. It has nothing to do with transactions. It's mostly an ! internal "housekeeping" method that is rarely needed. ! See also L</disconnect> and the L</Active> attribute. The C<finish> method should have been called C<cancel_select>.
