0

After a query in MySQL, in order to avoid the Warning: mysql_fetch_assoc() expects parameter 1 to be resource, boolean given error, I've done the following check:

if($result != null){
    while($row = mysql_fetch_assoc($result)){
         //Do awesome things        
    }
}

I don't want to do anything if the result is empty, so the if() is not required. I'm sure that it's possible to do that check in a better way. Any idea?

Andriy M
  • 76,112
  • 17
  • 94
  • 154
ZanattMan
  • 746
  • 1
  • 7
  • 26
  • 2
    Actually you should **NEVER** get such a error - your every query should be syntactically valid. So the idea - just don't write wrong queries. Yep, it's that simple. – zerkms Apr 10 '13 at 11:09
  • 3
    You are using [an **obsolete** database API](http://stackoverflow.com/q/12859942/19068) and should use a [modern replacement](http://php.net/manual/en/mysqlinfo.api.choosing.php). – Quentin Apr 10 '13 at 11:09
  • 1
    I assume $result is from mysql_query, which either returns 1) a resource, 2) TRUE (if an UPDATE/INSERT/DELETE/etc succeeded) or 3) FALSE (there was an error) - I don't think it ever returns NULL. Your if can be shortened to `if ($result) {` – James Apr 10 '13 at 11:11

1 Answers1

2

I don't want to do anything if the result is empty

You already cover that part in your code (the part: "if the result is empty").

However you don't cover the part if there was no result to fetch from (non-result). You need to check against TRUE/FALSE:

if ($result) {
   # there was a database result - empty or not
} else {
   # there was no database-result to fetch from.
}

This is a common problem btw, so take care whenever you deal with return values from a previous function. Many functions and libraries have the problem that they return more than one type therefore it is important that you check for the return type before you continue.

M8R-1jmw5r
  • 4,896
  • 2
  • 18
  • 26
  • "# there was no database-result to fetch from." --- that's incorrect. And the whole answer is just wrong. `$result` isn't actually a query result, but a handler. – zerkms Apr 10 '13 at 11:11
  • 1
    That's not common - if you write correct queries - you should never experience such error. – zerkms Apr 10 '13 at 11:13
  • @zerkms: It's not a handler it is a resource-identifier. The resource-identifier of something commonly called *Database Result*. If you're familiar with the concepts of objects in computer memory, you can also more correctly call it an object identifier. – M8R-1jmw5r Apr 10 '13 at 11:14
  • does it change anything? The solution - is to fix the roots of the issue, not the consequences. – zerkms Apr 10 '13 at 11:15
  • 1
    @zerkms: Database libraries are often client libraries and need to deal with typical error cases, e.g. the database-connection goes away. That are error situations you can not prevent by writing perfectly correct SQL. – M8R-1jmw5r Apr 10 '13 at 11:15
  • oops, yes, it makes sense. But still, I can bet OP just generates messy queries ) – zerkms Apr 10 '13 at 11:17
  • 3
    @zerkms: A better answer probably would have suggested an object oriented client library with throwing exceptions enabled. Those normally are more helpful to distinguish between exceptional failures and the self-made problems with wrong SQL queries. For example by using [PDO with exception throwing enabled](http://php.net/pdo.error-handling). – M8R-1jmw5r Apr 10 '13 at 11:19