From the DBI documentation:
And also says:When all the data has been fetched from a SELECT statement, the driver + should automatically call finish for you. So you should not normally + need to call it explicitly except when you know that you've not fetc +hed 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 selectrow_* + methods may be better anyway. Adding calls to finish after each fetc +h loop is a common mistake, don't do it, it can mask genuine problems + like uncaught fetch errors.
Calling finish resets the /Active attribute for the statement. It may +also make some statement handle attributes (such as NAME and TYPE) un +available if they have not already been accessed (and thus cached). The finish method does not affect the transaction status of the databa +se connection. It has nothing to do with transactions. It's mostly an + internal "housekeeping" method that is rarely needed. See also /disc +onnect and the /Active attribute.
Update: The DBI docs (same link) also says for the execute method:
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.
In reply to Re: Re: DBI (Prepare once execute many fails)
by Itatsumaki
in thread DBI (Prepare once execute many fails)
by ColtsFoot
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |