On 13-Jun-2006 Ron Savage wrote:
> On Mon, 12 Jun 2006 15:24:55 +0100 (BST), Martin J. Evans wrote:
>
> Hi Martin
>
>>> This seems to fall into the category of the first quote from the
>
> I saw the original post, and expected someone else to answer.
>
> I don't agree that it falls in the first category. I strongly suspect you'll
> have to amend all (sic) your code, to call 'finish' /unless the 'fetch'
> exhausts
> the returning data/. I think you're reading the docs based on wishful
> thinking
> and not on what they really mean.
Ok, so we disagree and my reasons are fairly straight forward.
1. The DBI docs clearly say:
"If execute() is called on a statement handle that's still active
($sth->{Active} is true) then it should effectively call finish() to tidy up
the previous execution results before starting this new execution."
2. The code I have works with DBD::ODBC, DBD::mysql and DBD::oracle
3. When I look at DBD::ODBC the first thing dbd_st_execute() does is call
SQLFreeStmt(stmt, SQL_CLOSE) if the statement is active.
4. When I look at DBD::mysql the first thing it does is call
mysql_stmt_free_result if the statement is active.
As DB2 is CLI is ODBC:
I think DBD::DB2 could be fixed with something like:
if (DBIc_ACTIVE(imp_sth)) {
ret = SQLFreeStmt(imp_sth->phstmt, SQL_CLOSE);
ret = check_error( sth, ret, "SQLFreeStmt failed" );
DBIc_ACTIVE_off(imp_sth);
}
at the start of dbd_st_execute which is effectively just calling dbd_st_finish
at the start of execute and this is probably the best solution.
When I add the dbd_st_finish call it works and I cannot as yet see any side
effects other than making DBD::DB2 do what the DBI docs say.
Martin
--
Martin J. Evans
Easysoft Ltd, UK
http://www.easysoft.com
