PFMaBiSmAd

Sorry to pick, but back-ticks are mysql specific and should be avoided whenever possible, not unconditionally added. The mysql PASSWORD() function should not be used by applications (already mentioned in reply #3 along with two alternate functions to use.) The mysql manual states why not to use it, along with all the applications that stopped working in the past and had to be fixed, so I won't repeat it here again. The PASWORD() or the more correct MD5() or SHA1() function would not be enclosed in single-quotes in the query, because that would make it a piece of string data. Again, amplexus, in your code posted in reply #20 in this thread, you did not have single-quotes around that term in the query, but you later added them. Why did you do that. After you get your code to work, you have a flaw in your password processing. You are retrieving the hashed password and putting it into the form field. When you submit that data and it gets updated, your current code is passing that value through the hash function (currently PASSWORD()) again and it will screw up the saved hash value so that the login won't ever work. If your intent of the password processing is to allow an administrator to set a new password, but to do nothing if the original was unchanged, you would need to add logic so that if the original hashed value gets submitted that you don't alter the saved value but if the submitted value is a new password entered by the administrator that you would want to pass the new value through the hash function and update the saved value. Edit: An alternative way of handling the entering of a new password might be to add a checkbox to each form that would tell the form processing code to use the value from the password field as a new password only when the checkbox is checked.

^^^ Must be from some other SQL. That's not working mysql.

Old session data files are removed by session garbage collection, which runs randomly based on session.gc_probability and session.gc_divisor when you execute session_start() statements. Rather that rely on incomplete bits and pieces of information you find posted around on the Internet, you should read the relevant section of the php.net documentation to find out the full story for whatever you are attempting to do with php.

Whatever value (array) was used when total_items(???); was called is what it operates on. That's the point of functions and their parameters. You write a function to perform a specific operation on the data it was passed. As far as the function cares, it does not matter where that actual data came from.

If I remember correctly, phpmyedit will let you create user interfaces to your database with just the features you want - http://www.phpmyedit.org/

Just read your error messages. They were created to help you find the error. Some programmer went to a lot of trouble to make sure that error message told you both where the header was at that was not working and where the output was at that was preventing it from working.

No it's not. It's a header error because you are outputting some characters to the browser before you try to send a header - Look at your code up to line 20 to find what output you are sending and eliminate that output. It looks to me that you have a closing php tag ?> at about line 16, about three new-lines, and an opening php tag at about line 20. Those three new-lines that are outside of the php tags are being sent to the browser. Why do you even have a closing php tag and an opening php tag there? It's all php code, don't even put a closing/opening php tag there in it.

The error, in your case, is due to the lazy-way short open tag <? Only use full opening tags <?php to insure that your php code will always be seen as php code.

In a way that is kind of funny, because your UPDATE query didn't have an incorrect * FROM in it, which you have since taken the * out of, until your Reply #8 in this thread. Immediately before reply #8, that part of the query was correct. Why did you change it?

If you echo mysql_error(); on the next line after the line with your mysql_query() statement, it will tell you why your query is failing (assuming the query is being executed.)

Based on your first piece of code (the form), you have a field named user_id. The WHERE clause in your update query would therefore need to have user_id, not id.

So, after you made that change, did you check if the HTML of your form was what you expected it to be? Writing code to accomplish any task involves breaking that task down into a series of steps and writing code to perform each step. Debugging code involves checking at each step if the results are what you expect or not. When you find the point where the results are not what you expect, I can guarantee that the problem lies before that point in the code.

From the URL, ud_id is empty (because your first piece of code is not setting $id) and the password is apparently stored as a hash value in your table (why are you putting it into a form field for editing?)

I don't see any code in your code that is setting the $ud_username, $ud_password, and $ud_id variables. Are you developing and debugging your php code on a system with error_reporting set to E_ALL and display_errors set to ON so that all the php detected errors will be reported and displayed? You should be receiving undefined NOTICE error messages for each of those variables. You would want to assign a value to each of those from the correct $_GET['...'] variable from your form. Edit: Also, your first piece of code implies that the passwords are stored as plain text in the database, while your second piece of code is applying the mysql PASSWORD() function to the entered password while updating it. Also, you should not use the mysql PASSWORD() function in your application. Instead use either md5() or sha1().

http://php.net/implode

The current symptom means that the query failed due to an error (I'm going to guess a problem with the table name or the column name or permissions or the database...) For debugging purposes (restore the code to what it currently is now when you are done), change the or die(.....) to or die(mysql_error()); P.S. Are you sure this code worked before it was moved to the current server? All the @'s tell me that whoever wrote this was in favor of hiding problems in the code rather than finding and fixing them. For example, @set_time_limit(3); won't ever produce an error unless that function has been disabled on the server (which is highly unlikely), but you would want to know if that was the case and you would want to have that error reported.

For anyone here to directly be able to help, it would take seeing what lines 1 - 25 of that file is.

^^^ You simply need to find what is being sent at or before line 7 in that file.

So, what is the current error message? Where does it say the output is occurring at?

So, what are lines 1 through 7 of login.php or point out which line in the code you posted is line 7? You likely have something on the line after one of the closing ?> tags. Why do you have multiple opening/closing php tags? Just put one opening tag at the start and one closing tag at the end of your php code.

There's no way the code you have been posting with the @'s in it could have been outputting the posted errors. You must have some other code at the file/line number being reported in the errors. Only the first error is relevant to this problem. The other errors are follow-on errors caused because the mysql_connect() is failing.

^^^ If that's your real code, take a look at it. You are using $dbName as the mysql username (2nd parameter in the mysql_connect.) Edit: And I'm going to guess that if you had actually read the mysql_connect() error message, you would have noticed that the user it mentions is actually your database name? You are the only one here who knows what your actual information is and can interpret what the error message means relative to what you are doing. And I'm guessing that the @'s in the code were just put there by you due to the error messages? Hiding the errors won't make your code work. It still won't work AND there won't be any error messages to tell you why it is not working.

The root word forms for research are 're' and 'search', i.e. keep searching until you find the answer. It doesn't mean run and ask someone to tell you some basic piece of information that could be found in 120 seconds of looking, then get bent out of shape when someone asks if you even tried to find the answer yourself. There's a reason that programming languages are one of the most heavily documented technical subjects on the planet, it is simply impossible to effectively use a programming language without making use of the documentation as the primary source of information about the basic elements of that language. Had the OP in that thread simply looked at the list of mysql functions, he would have found what he was looking for AND he would have also been able to read all the relevant information about the function he found so that he would know if it was an equivalent for the function he was trying to replace. He might have even learned if there was a better way to accomplish the same task. Instead the OP was looking for a lazy-way short-cut and those who attempt to take short-cuts in programming often trip and fall down along the path and end up taking longer to accomplish what they are attempting. That thread (and those like it) boil down to taking the time to learn something about a technical subject like a programming language vs do the least amount of work possible and taking short-cuts that end up taking longer than it would have taken to just research what you are trying to find out.

This topic has been moved to Miscellaneous. http://www.phpfreaks.com/forums/index.php?topic=308897.0

As Pikachu2000 wrote, either one of the three pieces of information is wrong or you don't have a database on that hostname setup with permissions for that username/password.