Is there an equivilant of the ASP rs.movenext in PHP (using mysql database), oir any other method which achieves the same results?

Thanks

Alice

    no rs.movenext, you will need to do a while statement to move through the object (in this case $result...

    the way I usually use is...

    while($row = mysql_fetch_array($result)) {

    do whatever
    fields are loaded into an array called $row
    if the user name is the second column then
    $row[1] is the user name

    }

    you don't specifically have to use $row. The principle here is that each row of the object that is loaded into $result is loaded into $row as an array, and the while statement addresses it. When the script contained within the while statement is complete, it will move to the next row until there is no more.

    One good thing about this is no dreaded "You have reached either BOF or EOF" error statement.

    HTH

    Jim Hawley

      Just relooked the answer, and wanted to add that

      mysql_fetch_row($result)

      is more attune to movenext.

      It retrieves the next row from the object (result identifier) as an array and moves the internal row pointer forward one. So each time you call mysql_fetch_row($result) it will return the next row from the object.

      Jim

        7 years later

        I know this is an old topic, but its relevant for what I'm doing now - based on the above I actually used to use the BOF AND EOF in ASP to work out whether a recordset was empty.

        The context in my instance being a user login - I'm looking for a username/password match in the database, I would then check 'if RS.BOF AND RS.BOF then' and continue assuming no match was found - how do I recreate this behaviour in PHP?

        Cheers, @sh

          $query = sprintf("SELECT 1 FROM users WHERE user='%s' AND pass='%s' LIMIT 1",
              mysql_real_escape_string($_POST['user']),
              sha1($_POST['pass']) // assumed SHA1 hashing used to secure pass in DB
              );
          $exec = mysql_query($query);
          
          if(mysql_num_rows($exec) == 0) {
              // no match
          } else {
              // match
          }

            Thanks for this - I'm actually using an MD5 function that utilises a private password too to further secure the encrypted password - I presume this is as acceptable as SHA1?

            So no trapping is required to avoid the BOF AND EOF behaviours of ASP, does PHP not even try to loop through the recordset if its empty? So I can just use...

            if(mysql_num_rows($QUERYHERE) > 0) {

            ...to check instead of...

            if RS.BOF AND RS.EOF then

            I'm not going to limit my query to 1 just so as to trap any instance of foul play, i.e. two instances of the same user in the database for any reason, should this occur I'll have a reporting mechanism within the script to alert me.

              ashleyhall wrote:

              I presume this is as acceptable as SHA1?

              Not really - the weakness of MD5 is due to the length of the hash (essentially).

              ashleyhall wrote:

              i.e. two instances of the same user in the database for any reason

              This should never happen, because in this type of setup (login system), you should have a UNIQUE key on the username column.

                I do have a unique key (MemberID) but that wouldn't prevent two users from having the same email/password - my 'registration' system will prevent it from occuring, its only really incase of someone tampering or screwing up.

                Perhaps I'm overparanoid when developing stuff like this!

                  If you want to allow only one registration per given email address, then it would be a good idea to add a unique index on that column. This will not only enforce that restriction, but will enhance the performance of your query, too. 🙂

                  As far as the "looping through the recordset", nothing is looped through when you do the mysql_query(). It's only when you do one of the mysql_fetch_() functions on the query result that you start looping through records, and if you get to the end of the recordset the fetch function will return false. Thus you see the typical PHP idiom of:

                  $sql = "SELECT * FROM table";
                  $result = mysql_query($sql);
                  if($result == false) // query failed
                  {
                     // log error, tell user they're out of luck
                  }
                  elseif(mysql_num_rows($result) == 0)
                  {
                     // tell user nothing was found
                  }
                  else
                  {
                     echo "<table>\n";
                     while($row = mysql_fetch_assoc($result)) // loops until false is returned
                     {
                        echo "<tr><td>";
                        echo implode("</td><td>", $row);
                        echo "</td></tr>\n";
                     }
                     echo "</table>\n";
                  }
                  

                    Also note that it's perfectly fine to have more than one UNIQUE index in a table.

                      Thanks guys, didn't realise that you could have two unique keys in a single table - so by making email a unique key as well, is it kinda cached and so speeding any queries relating to it?

                        Among other things (e.g., the DBMS can maintain a UNIQUE index more efficiently because it knows there won't be duplicate values for a given key, and it knows that when it's searching on a UNIQUE field, it can stop searching as soon as it finds one matching record - there won't be any more.)

                          Nice one, thanks for your help!

                            bradgrafelman;10878993 wrote:

                            No problem. Don't forget to mark this thread resolved.

                            That will not be possible since she is not the thread originator. :p

                              Oopsie. :o That's what happens when old threads get hijacked! :p

                                Wrong, I was able to - even though I didn't create the thread!

                                  After realizing my mistake, I went ahead and marked it resolved (just in case someone else stumbles across this thread's title in the future).

                                    Write a Reply...