in reply to sth fetch only grabbing back first result

You want to use the $sth->fetchrow_hashref, or $sth->fetchrow_arrayref functions. Check out perldoc DBI. You probably want something like this
my $data = qq(SELECT search, engine, time FROM searches WHERE DATE_SUB +(CURDATE(),INTERVAL 7 DAY) <= time); my $sth = $dbh->prepare($data); $sth->execute() or die $dbh->errstr; while(my $r = $sth->fetchrow_hashref) { print "$r->{search} $r->{engine} on $r->{time}<br>"; }

Replies are listed 'Best First'.
Re^2: sth fetch only grabbing back first result
by friedo (Prior) on Aug 10, 2006 at 18:52 UTC
    Maybe I'm being dense, but I don't see how this solves the OP's problem. The bind_columns/fetch code looks right to me. I think it's probably an SQL or data problem.

      It may not solve Anonymous Monk's problem, but it does remove a specific issue: fetch is not a documented method of statement handles, so its behavior is effectively undefined. Switching to a documented method such as fetchrow_hashref should result in predictable behavior from the statement handle, which lets us focus on whatever may be causing the behavior. And if changing to the defined method results in the problem going away, well that's just groovy.

      Update: Okay, so it is documented after all. Took me a while to scan through DBI, but fetch is an alias for fetchrow_arrayref with the apparent difference that:

      If any method except fetch fails, and "RaiseError" is not set, selectcol_arrayref will return undef. If fetch fails and "RaiseError" is not set, then it will return with whatever data it has fetched thus far. $DBI::err should be checked to catch that.

      So it's there in the docs after all, but it's not nearly as well defined as the others. That's what I get for just scanning through the headers of the POD rather than looking at the examples. Oy.

      Yeah, I'm an idiot. Sorry about the response. Should have picked up the err in the SQL.