On Mon, Dec 13, 2010 at 05:30:10PM +0000, Martin J. Evans wrote: > See RT http://rt.cpan.org/Public/Bug/Display.html?id=63550 which started this > off. > > DBD::ODBC optimises calls to the do method when no parameters are > involved. Normally do is just a shortcut for prepare/execute except it > should only be for non-result-set generating statements and hence does > not return a statement handle. ODBC can optimise the do method to > simply call SQLExecDirect instead of the normal SQLPrepare/SQLExecute > (one round trip and other advantages). DBD::ODBC has been this way for > years. > > However, the person reporting this issue is attempting to use the > handle passed to an error handler when do fails to obtain the > Statement attribute. The handle DBD::ODBC passes in to the error > handler is the connection handle as DBD::ODBC never created a DBI > statement handle and hence there is no Statement attribute to access.
Actually, the database handle _does_ have a Statement attribute http://search.cpan.org/~timb/DBI-1.615/DBI.pm#Statement Feel free to patch the docs to change "most recent prepare method" to "most recent prepare() or do() method". > Is DBD::ODBC breaking the rules here with this optimisation? No. The DBI docs for do() should have a note along the lines that "Drivers are free to avoid the overhead of creating an DBI statement handle for do(), especially if there are no parameters. In which case error handlers, if invoked during do(), will be passed the database handle." The docs for drivers using this approach should note the fact that a statement handle isn't created, and that error handlers like HandleErr will be called with the $dbh. Tim.
