http://qs321.pair.com?node_id=1091320


in reply to Re: DBI and finish (risk of calling finish twice)
in thread DBI and finish

Actually, calling $sth->finish becomes important only on the cached handles when not all of the data was fetched. Otherwise, next "execute" on that handle may result in error. Though it all depends on the actual driver. Many (or is it all now?) drivers automatically do "finish" for the handles that are "executed" again. So, if one works with such driver, then one does not need "finish" at all.

BTW, the above behavior of the drivers potentially masks errors of simultaneous use of the same handle :) YMMV.

As to "dangers" of using "finish", this might be exaggerated. After all, one should check for errors right after the call to "fetch", if this is not done, then clearing that error state later by "finish" does not play any role. Mostly, these "finish" calls are just useless. IMHO.

BTW. Doing "undef $sth" on statement with active transactions results in ROLLBACK, not COMMIT. At least this is what I was getting with SQLite :)

  • Comment on Re^2: DBI and finish (risk of calling finish twice)

Replies are listed 'Best First'.
Re^3: DBI and finish (risk of calling finish twice)
by Anonymous Monk on Jun 26, 2014 at 10:14 UTC

    ... cached ... Though it all depends on the actual driver ...

    I doubt that :) See inside DBI.pm look for "sub prepare_cached"

      Well, "cached" does not mean only "prepare_cached" :) Whichever caching mechanism is used, prepared statement with unfinished fetch may introduce problems. I guess you've seen the description of $if_active flag for DBI::prepare_cached :) That is why, calling finish in this case might be important.