No that wasn't the case here. Each select only produces 1 result row.
So, I just did a
$sth->execute(....) or die(...);
$href = $sth->fetchrow_hashref();
In the method... the method is executed in a loop within the caller.
With Sybase, it was necessary to insert a finish after the call to
fetchrow_hashref... from what I recall, the error happened at compile time
and didn't even attempt execution (I could be wrong about that, though).
So for me, there were 2 morals of the story here. First, in regards to
the original question, it's not necessary to keep doing a prepare just
because you call finish on the statement handle. Second, avoid Sybase
whenever possible. I've been doing most of my DBI development with
Informix and when I started working with Sybase it's been one problem
after the other... i.e. no placeholders in statements executing stored
procs, can't have multiple statement handles open on a db handle with
AutoCommit off, etc. etc. Some of this may be due to the fact that the
Sybase driver is not current (I have no choice), but the concensus I've
heard from people who've worked with Sybase and another db such as Oracle,
Informix, DB2 is that Sybase is garbage.
On Wed, 28 Mar 2001, Alexander Farber (EED) wrote:
> Hi Curt,
>
> Curt Russell Crandall wrote:
> > I ran into a similar problem with Sybase. I had a statement prepared
> > using placeholders (a select statement) and I had to loop several times as
> > I processed transactions and each time through the loop I had to execute
> > the prepared statement. Perl and/or Sybase complained that I needed to
> > finish the statement handle.
>
> maybe the reason for that was, that you had several data sets
> returned by 1 statement and you had to use this way (described
> in "perldoc DBD::Sybase"):
>
>
> do {
> while($d = $sth->fetch) {
> ... do something with the data
> }
> } while($sth->{syb_more_results});
>
>
> Regards
> Alex
>
> > Using finish doesn't mean you have to keep repreparing the statement
> > handle... according to the Cheetah book, it's a rarely used functions used
> > for "internal housekeeping". In my program, I prepare my frequently used
> > select statements in an init method and assign the statement handle to an
> > object attribute. I have no need to prepare the statement more than once
> > and explicitly finish()'ing a handle after a fetch* didn't cause any
> > noticable decrease in performance. So I don't think using finish is any
> > sort of a "nasty workaround". I would just try to remove the multiple
> > prepare()'s and prepare the statement up front, then just finish() after
> > each fetch*. Hope it helps.
>
