SQL error VERY BASIC problem

[TwitterRooms]

hi just learning SQL stuff getting this error tho
Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in

this is the script im using

<?php
$con = mysql_connect("localhost","mysite_test","test1");
if (!$con)
{
die('Could not connect: ' . mysql_error());
}
mysql_select_db("my_db", $con);
$result = mysql_query("SELECT * FROM test_members");

while($row = mysql_fetch_array($result))
{
echo $row['FirstName'] . " " . $row['LastName'];
echo "<br />";
}
?>
i know it will be something silly but i'm stuck lol

[fastsol1]

After this line
$result = mysql_query("SELECT * FROM test_members"); Put this

echo mysql_error(); and it should tell you why it's failing.

[traq]

mysql_fetch_array(): supplied argument is not a valid MySQL result resource
...tells you everything you need to know.

look at your mysql_fetch_array() call: the "supplied argument" is $result. PHP says $result is not a valid result resource.

So, what is it? $result came from mysql_query(), a few lines above. PHP (php.net/manual/en/function.mysql-query.php) says mysql_query() returns a result resource, or "FALSE on error". So, if $result is not a resource, then it's FALSE, and that means there was an error in your query.

Check the result before trying to use it:
<?php
$con = mysql_connect("localhost","mysite_test","test1");
if (!$con)
{
die('Could not connect: ' . mysql_error());
}
mysql_select_db("my_db", $con);
$result = mysql_query("SELECT * FROM test_members");

// check $result :
if(!$result){ die( mysql_error() ); }
// (...but never use die() in your production error handling.
// it's fine for development, but _not_ live sites.)

while($row = mysql_fetch_array($result))
{
echo $row['FirstName'] . " " . $row['LastName'];
echo "<br />";
}
?>

[TwitterRooms]

i was putting the prefix twice daterbase name and table name
mysql_select_db("my_db", $con);
$result = mysql_query("SELECT * FROM test_members");



Thanks guys for your help

[kuau]

traq: Why do you say never to use "die" in a production environment? Now I am worried that all my sites are insecure but I don't know why. I always use this as the connection script...


$connection = mysql_connect($server,$user,$pass) or die("Couldn't connect to $db_name database.");
$db = mysql_select_db($db_name, $connection) or die("Couldn't find $db_name database.");

Thanks.

[traq]

It's not always a security issue as much as a usability issue: die() can leave your page in a messy, half-finished state. it's better to abort bad script by showing an error page instead (IMO, even a blank page is preferable). In addition, die() can leave your script/server in a "bad place" - if you've started some process (a socket connection, writing to a file, etc.), letting it "hang" might cause further errors.

Having said that, however, your specific die() message does tell us something we shouldn't know: the name of the database you're using. This is helpful in development, but bad for production, since it makes a malicious user's job easier.

might wanna read this (http://www.phpfreaks.com/blog/or-die-must-die) for more perspective. :)

[kuau]

Hi Adrian: The only time the "die" comes into play on a live site (for me) is when the hosting company is having hardware problems. I have no control over that. All I can do is call the hosting company but they are really fast at addressing problems so it is usually fixed in a few minutes. As the problems are temporary, I assume that the viewer would press the back button and try again. I assume they would see a message such as "Couldn't connect to cars database" and then the server logs the following message in the php error_log...


PHP Warning: mysql_connect() [<a href='function.mysql-connect'>function.mysql-connect</a>]: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (11) in /home/user/public_html/php/connectdb.php on line 7

I read that article about 'die' and understand that there are better ways to deal with the errors. I read some of the other links, but often the php manual assumes that you understand all the terminology, which I don't. As I am pressed for time, would it be sufficient for me to simply change the message after die to "Temporary connection problem... Please try again." ?

Thanks. :)

[djr33]

There's an exception when I would suggest using die(). (Actually, the 'real' command is exit;, for which die is an alias-- not important.)

If you have a secure page and someone is trying to access it without permission, then place die() at the top of the page. Of course this should also solve the problem of loading a half-finished page. Don't do that in the middle of a page, although even then it would be secure. die() guarantees that the secure information below that point is never shown to the user.

This method should not be used if it's a place that a legitimate user could arrive by mistake (for example, a typo in the password), but only if they are actually trying to hack into something.

Then it's best if this actually results in a blank page as traq said. Or you could use include() to add your 404 page, and I do that fairly often. If the page should not exist except for someone with permission, then give a 404. Or just a blank page would be fine, but it hints that there is in fact something to be found there.


As for mysql queries, that's not really a location I'd use die() in. You've probably seen a page with a PHP error like that, and at least to me, it looks really unprofessional. On the other hand, you're right-- it's very rare that it would occur, so it's not a big problem.

Another option is to use a redirect if it's still early enough in the page generation process.

[traq]

all good points.

as Daniel alluded to, it's a very good idea to use die() ( exit() ) right after you use header() to redirect someone - even if the user doesn't see it, the rest of your script can keep running and cause problems on your server.

as to your database error message, anything that doesn't reveal any details is okay.

Your users probably don't care (or understand anyway) what the specific problem is. Just tell them there was a problem, that it was logged and will be addressed, and that they can try what they were doing again.

[djr33]

I recently had some problems with one of my sites and a database connection. It sent me an email claiming there was a database problem, and I never saw the error. I think I finally fixed it (or at least I'm not getting any emails and the site continues to work).
So the point I want to add is: actually do create a log, at least if you ever have problems you'll want to make one. That way you can track the information such as URL, IP, time, etc. If not, you'll never be able to fix it, if you're even aware that something went wrong.

[Superdog]

Personally I feel that it is tantamount to treason to use die() in a commercial environment unless it's for external access in a bandwidth limited situation.

What I mean by that is that while it's almost invariably better to dynamically create or redirect to an error page rather than just executing die() when things go badly wrong, if you are using a PHP script to output data from, for instance, a database to a mobile device app with limited bandwidth - then it is often far more efficient to error handle the blank return data rather than cramming a whole error page down a bandwidth limited line...

Just my two cents!

[djr33]

Interrupting a page while it loads and giving an error message of any kind, especially with die() stopping any other content from loading is of course bad.

But there are two cases where this is acceptable:
1. If there is no legitimate reason for the user to be in a location (eg, hidden admin page), then all you're doing is annoying hackers. Of course it shouldn't be something a legitimate user could click by accident. For security, nothing is better than die().
2. If you use it at the right part of the page and have a redirect.

And maybe a third would involve a case where an endless loop is stopped using die() as a last resort. Any alternative is better than this, but I can imagine a situation where programming such an alternative would be difficult.


The habit of tutorials to suggest using or die('Error message'); is a bad one, but the function is not useless.



There's one other case when I've used die() that is a little complicated, but very useful if it happens to apply in your situation. If you're using OOP, objects can have a "destruct" function that is automatically activated when the script ends (unless you intentionally unset the objects earlier). This can be very useful. For example, I've used this for templates so that it automatically adds the </html> tag (along with other things, like Javascript that goes at the end of the page). The only problem with this is because it's something that is set early (by creating such an object) and not controlled at the end of the page, if you do need an exception (for example, skip those Javascripts, and manually use only the </html> tag), then you can use die() to stop those things from executing automatically-- die() stops execution immediately so nothing else is processed.


The real problem with die() is that it creates broken pages (skipping lots of close tags for example). But that's a usage error, not a problem with the function itself.

[traq]

Also (@superdog):
Bandwidth absolutely does not need to be an issue. How many bytes are needed, realistically, to say 'sorry, there was a problem?

[djr33]

I think the idea was that if your account has 0 bandwidth left, then using die() to disable any output could stop extra charges. But two problems with that are 1) it's hard to know when that's the case (within PHP automatically), and 2) I think the requests count as bandwidth, even though they're very small.
I can't ever imagine being in that situation, though.