-1

Running a program which includes two queries. When I run either query alone it works but when both queries exist within the code it breaks.

$qry = "SELECT * FROM temp_user WHERE email='$email' AND pin='$pin'";
$result = mysql_query($qry);
$num_rows = mysql_num_rows($result);

$qry2 = "SELECT * FROM email WHERE email='$email'";
$result2 = mysql_query($qry2);
$num_rows2 = mysql_num_rows($result2);

How can I fix this?

EDIT:

For those asking what do I mean by it breaks, here is an image.

enter image description here

Error from log.

PHP Parse error: syntax error, unexpected '}' in /Users/philipkirkbride/Documents/apps/Today_test/confirm.php on line 30

Full code of page is

<?php
include 'connect.php';

$pin = $_GET['pin'];
$email = $_GET['email'];

$qry = "SELECT * FROM temp_user WHERE email='$email' AND pin='$pin'";
$result = mysql_query($qry);
$num_rows = mysql_num_rows($result);
if ($num_rows!=0){
    print "create user and delete temp";
    $sql = "INSERT INTO pin VALUES (DEFAULT, '$pin', '$email')";
    $result = mysqli_query($con,$sql);
    if ( false===$result ) {
      printf("error: %s\n", mysqli_error($con));
    } else {
        // Delete user from temp table
        $sql2 = "DELETE FROM temp_user WHERE email='$email' AND pin='$pin'";
        $delete = mysqli_query($con,$sql2);
        // Make query to see if user is new or existing
        $qry2 = "SELECT * FROM email WHERE email='$email'";
        $result2 = mysql_query($qry2);
        $num_rows2 = mysql_num_rows($result2);
        // Need to add a snippet to add a row to the email table, make sure to check user doesn't have an email already in table
        if($num_rows2==0){
            print "email doesn't exist, create new user."
            // $date = new DateTime;
            // $sql = "INSERT INTO email VALUES ('$email', '$date')";
            // $result = mysqli_query($con,$sql);
        }else{
            print "email exists already";
        }
    }
}else{
    print "Account request not found";
}
// End connection
mysqli_close($con);
?>
Philip Kirkbride
  • 21,381
  • 38
  • 125
  • 225
  • 9
    Can you give us more than "it breaks"? – Mike B Apr 17 '13 at 22:08
  • 2
    What do you expect to happen? What really happens? What have you tried to fix it and where did that attempt fail? – George Cummins Apr 17 '13 at 22:09
  • 1
    not related to answer, just to propogate good behavior ... `mysql` is deprecated. please use `mysqli`. – PlantTheIdea Apr 17 '13 at 22:12
  • 2
    if you're writing new code, it's worth telling you that PHP has deprecated the `mysql_xxx()` functions. For new code you should use the PDO library instead. (if it's existing code that already uses `mysql_xx()` then carry on, but you need to make plans to convert it, as future versions of PHP will drop the old mysql extension. – Spudley Apr 17 '13 at 22:13
  • 1
    Is your table name (for the second query) email and you have a field email in it? – zkanoca Apr 17 '13 at 22:13
  • there is nothing wrong with this code .. – dbf Apr 17 '13 at 22:15
  • 2
    ...you mean aside from the fact that it isn't working, right? – Craig Tullis Apr 17 '13 at 22:21
  • We still don't know what isn't working. It's still possible that there is a `temp_user` table and no `email` table in his database. – Nathaniel Ford Apr 17 '13 at 22:23
  • We do actually know _that_ much. Although he didn't indicate what specific error is occurring, he **did** indicate that either query run alone executes successfully. – Craig Tullis Apr 17 '13 at 22:54
  • @PhilipK server error 500 translates to about "there was something wrong on the server side" - could you take a look at the error logs or execute the script from the shell to see the actual error message? – eis Apr 18 '13 at 09:46
  • @eis I didn't even know about the log file, thanks for pointing it out will be very useful in the future. Updated my question with the error. – Philip Kirkbride Apr 18 '13 at 14:39
  • @PhilipK - you need to add the rest of your code - the error is on a previous line. – andrewsi Apr 18 '13 at 15:00
  • @andrewsi Added full code – Philip Kirkbride Apr 18 '13 at 15:21
  • @PhilipK - you're missing a semi-colon on the `print` call on line 26 – andrewsi Apr 18 '13 at 15:23

2 Answers2

4

Try calling $result->close() before you call the second query, in order to release the connection. Your PHP script hasn't finished executing yet, and your previous result is holding that connection open. In general, it is good practice to explicitly clean up these kinds of resources rather than leaving it to the runtime.

EDIT: I believe @eis is correct that since this is the older (and deprecated, incidentally) mysql_ api, that the proper call would actually be mysql_free_result($result).

ANOTHER EDIT: I put this comment under @eis's answer, but I figure it bears bolder type, because @eis's answer was absolutely right and should not have been down-voted:

Just to elaborate redundantly on the whole buffered vs. unbuffered thing; the concept is that a buffered query will read all of the results back from the database into a buffer, then release the connection automatically (this will happen synchronously, so that the connection is free for another call immediately after the buffered call returns). An unbuffered query will essentially open the connection and hand back a reference to a database server cursor, from which you will then need to fetch records. As long as there is something left to fetch, the cursor is still open, and you won't be using the underlying connection for anything else. Or you can call mysql_free_result() and free the connection "early" (without reading all of the rows from the cursor first).

Craig Tullis
  • 9,939
  • 2
  • 21
  • 21
  • 2
    as this is legacy mysql_ api, I do think you need to use mysql_free_result($result) instead of $result->close(), like I proposed (and got downvoted for :p) – eis Apr 17 '13 at 22:29
  • I was surprised you got downvoted. I might add that I have read elsewhere that PDO isn't really used by folks inside Oracle and they aren't all great-guns about maintaining it, so +1 for recommending mysqli. – Craig Tullis Apr 17 '13 at 22:33
  • Did http://www.php.net really just go down? I guess that earlier "mysql_query() returns an object...really?" comment disappeared. I'm not sure what one would expect it to return; a poodle? According to the docs, it returns a resource, or false. A "resource" (ahem) would be one of them there object thingeys, seeing as how a resource is defined as a reference to external stuff, "external stuff" being specifically defined only in the context of the specific resource type. – Craig Tullis Apr 17 '13 at 22:36
  • You're probably right about needing to call mysql_free_result($result) instead of ->close(). – Craig Tullis Apr 17 '13 at 22:38
  • 1
    objects weren't around in PHP at the time mysql_ was there. It came as part of mysqli_. For mysqli_ results, you can call ->close(). – eis Apr 17 '13 at 22:38
  • Object, schmobject. Okay, fair enough. :-) I'm not just a _huge_ fan of PHP pre-5.x, in any event. But the basic concept here is that the poster has opened a connection that isn't going to be free for a second call until he's either fetched all the records or released the resource, right? The principle (releasing resources) is pretty universal, as well, not just a PHP thing. – Craig Tullis Apr 17 '13 at 22:48
  • Thanks for the detailed answer. I tried 'mysql_free_result($result)' before doing the second query. It didn't seem to fix the problem. BTW I added an edit to show how it's breaking. I'll have to try reformatting it to mysqli later tonight, hopefully that fixes my problem. – Philip Kirkbride Apr 18 '13 at 01:26
3

you should actually either 1) read the result that you retrieved or 2) free it (mysql_free_result)...

You have two distinct queries. If you don't read the result or close it in between, it might not let you run a new one.

(I don't see the point doing the queries if you don't actually need the actual items. Use SELECT COUNT(*) if you are not intrested in the actual items, and just about the count.)

eis
  • 51,991
  • 13
  • 150
  • 199
  • 1
    would be interested to get feedback about the -1 – eis Apr 17 '13 at 22:10
  • 2
    It wasn't my vote, but you're not actually answering the question. – Nathaniel Ford Apr 17 '13 at 22:11
  • 1
    I am. The question is "how should I fix this". It will be fixed by reading the result in between the queries. – eis Apr 17 '13 at 22:11
  • 1
    mysql_ API won't allow you to run two distinct queries without reading the result in between... – eis Apr 17 '13 at 22:12
  • I believe you are incorrect. Per the documentation mysql_free_result need only be run if you're concerned about memory usage. Apart from that he is calling separate queries into separate result variables; that is doable: http://stackoverflow.com/questions/6573928/run-multiple-mysql-queries-from-php-why-is-this-not-working – Nathaniel Ford Apr 17 '13 at 22:16
  • @NathanielFord as per my recollection, and [this link](http://php.net/manual/en/function.mysql-unbuffered-query.php), "You are NOT required to read all rows from the resultset when using unbuffered query, you may opt out at any time and use mysql_free_result. Imagine looking at 1 million row when the first 50 suffice? Just free the result and you are good to go again." - so if unbuffered queries are used, freeing results is needed to go on, if you don't read the actual results. – eis Apr 17 '13 at 22:18
  • 2
    but ok, if these would be unbuffered, mysql_num_rows wouldn't work either... so I guess I'm wrong then. – eis Apr 17 '13 at 22:19
  • Nothing in that link suggests that you MUST read anything out of a resultset in order to make another query into the database. – Nathaniel Ford Apr 17 '13 at 22:19
  • @NathanielFord not even "You also have to fetch all result rows from an unbuffered SQL query before you can send a new SQL query to MySQL, using the same link_identifier."? – eis Apr 17 '13 at 22:20
  • You're talking about the unbuffered function, not the buffered one. I think Craig's response may provide insight: if mysql_query is buffering and not complete, perhaps the second cannot start. – Nathaniel Ford Apr 17 '13 at 22:24
  • 1
    well... I'd say that goes into same category I was proposing. As this is mysql_ api, you cannot call $result->close() anyway, but you need mysql_free_result() I was referring to. – eis Apr 17 '13 at 22:27
  • Just to elaborate redundantly on the whole buffered vs. unbuffered thing; the _concept_ is that a "buffered" query will read all of the results back from the database into a buffer, then release the connection automatically. An _unbuffered_ query will essentially open the connection and hand back a reference to a database server cursor, from which you will then need to fetch records. As long as there is something left to fetch, the cursor is still open, and you won't be using the underlying connection for anything else. Or you can call mysql_free_result() and free the connection "early." – Craig Tullis Apr 17 '13 at 23:00