in reply to perl, mysql: "fetchrow_array failed: fetch() without execute()"

If it's the same problem as the other thread, proper use of my will fix it. Don't you use use strict; use warnings;?

my $ID = ...; my $query = ...; my $sth = $dbh -> prepare($query); $sth -> execute; my @row = $sth -> fetchrow_array;

Another possibility is that there was an error performing the execute. Since you don't check for errors, did you specify RaiseError => 1?

Two other comments:

Replies are listed 'Best First'.
Re^2: perl, mysql: "fetchrow_array failed: fetch() without execute()"
by Marshall (Canon) on Dec 29, 2008 at 09:57 UTC
    This sequence of statements can be easier:
    $query = "select * from finalLevel3 where id=\"$ID\";"; $sth = $dbh -> prepare($query); # I would suggest this: my $query = $dbh->prepare("SELECT * FROM finalLevel3 WHERE id='$ID'");

    I personally like to captialize the SQL key words, but preferences vary. Also the single quote within the double quote will expand $ID just fine. There is no need for \" in this situation. I was amazed when I learned this.

    I am also a bit confused about this:

    foreach $item (@{$clusters}) { #..... }

    I would think that since you are iterating over clusters, that something like this would be more clear:

    foreach my $cluster (@$clusters) { #..... }
    So when do you need the extra {}? You need this when dereferencing an indexed expression, but not a non-indexed one. You also need the extra {} to make a list from a list ref returning function.
    my @list = @{listRefReturningFunction()}; #also consider: my $r = {"a" => [1,2,3,4], "b" => [5,6,7,8], }; print @{$r->{"a"}}; #prints 1234 #here print @$r->{"a"} won't work #because this is a subscripted expression # now with list... my @x =(1,2,3,4); my $xref=\@x; print @$xref; #prints 1234 also #this works because there is no subscript

      Did you really mean to reply to my post? It seems you ignored everything I said.

      This sequence of statements can be easier:
      my $query = $dbh->prepare("SELECT * FROM finalLevel3 WHERE id='$ID'");

      Just adding quotes around the contents of $ID doesn't properly convert it from arbitrary text into an SQL string literal. It's an bug or injection attack waiting to happen. It's also very inefficient. You're compiling the query over and over and over again. The following is a whole world better:

      # Outside of loop my $sth = $dbh->prepare("SELECT * FROM finalLevel3 WHERE id=?"); $sth->execute($ID);

      I would think that since you are iterating over clusters, that something like this would be more clear:

      If you look closely, you'll notice he's actually iterating over the cluster indexes, so the following would be even better:

      for my $i (0..$#$clusters)

      So when do you need the extra {}? You need this when dereferencing an indexed expression, but not a non-indexed one.

      @{ foo() } would also need it. The correct answer would be "Pretty much anything other than a variable name" or maybe even "Everything other than a variable name".

        Ok, I maybe I hit a wrong button and replied at the wrong level. I am a "new guy" in this forum and I say, please don't take offense! None at all was intended! I only had two main points:
        1) simple SQL statements - unnecessary escapes like: \"
        2) simplify de-referencing a list ref

        I hear: " Just adding quotes around the contents of $ID doesn't properly convert it from arbitrary text into an SQL string literal... "

        From my experience so far, "prepare" appears to do exactly that! The prepare method is much smarter than I would have thought. This is what amazed me! And I mentioned this in my post. This thing gets a string from Perl and then applies its own "rules".

        How "prepare" gets the "real" value of $ID is a mystery to me. But it does! I have several programs that work with this syntax.

        As far as de-referencing lists, we are "on the same page.