in reply to DBI, prepare_cached, finish, and forks

  1. That's right. Don't use the same $dbh in more than one process.
  2. If you fetch all rows and don't exit the loop early, there is no need to call finish(). on sth3 and 4, you can either call prepare_cached, or move the prepare to right before the sth2 fetch loop (which would be my preference...even calls to prepare_cached cost something).
  3. It probably won't make a big difference, but bind_columns w/fetch is supposed to be faster.

Replies are listed 'Best First'.
Re^2: DBI, prepare_cached, finish, and forks
by Anonymous Monk on Feb 24, 2006 at 01:56 UTC
    Why thank you!

    2. So if I were to call prepare_cached() within the condition (so I'm not preparing the statement if I don't need it, since there are multiple ones), you're saying that I don't need to call finish() on it?

    I seem to remember getting errors if I don't call the finish() on my statements... are you saying that as long as I fetch all the returned rows on either a prepare() or a prepare_cached(), I don't need to use a finish()?

    I'd assume it's still best practice to use a finish()?
[reply]

      > I'd assume it's still best practice to use a finish()?

      Nope. From the DBI docs:
      "Adding calls to finish after each fetch loop is a common mistake, don't do it, it can mask genuine problems like uncaught fetch errors."
[reply]
        Asho!

        I guess I was paying more attention to the:
        "free up resources"
        part of the documentation.

        Will I run into problems using the same variable name $sth in multiple calls without a finish(), like this: 
        $sth=$dbh->prepare($sql);
$sth->execute;
while(($var)=$sth->fetchrow_array) { ... };

$sth=$dbh->prepare($sql2);
$sth->execute;
while(($var2)=$sthf->fetchrow_array) { ... };

        [download]
        I'm trying to make sure I understand how to do it right!
[reply]
[d/l]

In Section Seekers of Perl Wisdom