PFMaBiSmAd

What does the following (added to your test code) show - echo $_SERVER['CONTENT_LENGTH']; Did the display of the echo ini_get() statement display exactly 8M or was it something like 8MB?

The thing that would help most, would be to use loops and array data structures. Even with functions, without having loops and appropriate data structures, you would still be faced with writing x amount of function calls that operate on individually named and hard-coded scaler variables (as call time parameters.)

The code is also mixing a mysqli connection with mysql functions, which won't work. You must use all the same family of database functions.

Your code is doing something that is causing this. Within your programming/troubleshooting ability and knowledge, you cannot troubleshoot the problem. You are asking people who are not standing right next to you to help you with what your code is doing. Without having enough of your actual code that you have specifically tested that produces/reproduces this problem, no one here can help you. We can only make guess that can be no better than the information that you have supplied. Since you mention redirecting, I will guess that you don't have an exit; statement after your header redirect and your code that is continuing to run while the browser performs the redirect is causing this. Second guess - your code is not testing if a form was submitted at all and upon the redirect is executing the update query again with a 1 for the pay value. Third guess - your code is dynamically getting the table name for the query and the logic is getting the wrong one or is putting the wrong one in. Fourth guess - register_globals are on and is overwriting your program variables from post/get/cookie/session variables.

There's nothing technically wrong with what you have posted that would cause the problem. How are you looking at the result that shows the 1.00 in the field? Perhaps something in the display logic is causing the symptom? Have you looked directly in the database table using your favorite database management tool? I suspect that your php logic is either executing another query (or the same one but with a 1 for the value) or something in your whole code is setting the value to a 1. Given that you have a $sql3, implying a $sql1, $sql2, and perhaps a $sql4,... posting enough of your code (less your database username/password) needed to reproduce the problem would be the quickest way of pinning down where the problem is.

The current (previously posted) code will 'log you in' when nothing has been entered because an empty string is equal to an empty string and the code is not really checking if anything was entered. It's actually checking if anything other than a space was entered and an empty string is something other than a space. The current (previously posted) logic contains many issues. You need to slow down and first define what you want to do, then write and test the code needed to perform each step that you have defined. Edit: The latest code posted also contains coding issues, such as not repeating the form code three times that only differ in an error message being displayed. That makes a wall of code. What happens when you want to change the look or layout of the form? You have to find and make the change three times. The form is also invalid (two <form > tags) and doesn't have a field named 'submit', so the posted code still won't work. Recommendation - slow down when defining, writing, and testing code.

Here's a couple of reasons why strtotime wouldn't be the best solution - 1) It requires an additional, relatively slow, parse and conversion to get a Unix Timestamp (strtotime calls mktime internally after the string has been parsed into its individual date and time components.) 2) Strtotime only works for a limited range of dates (1901/1970 to 2038), depending on php version, operating system, and 32/64 bit version of php/hardware/operating system.

Have you checked if $words[$i] has the value you expect? Do you have any white-space as part of the data in the $words array that would prevent a comparison from working? Are the letter cases the same? If $words is already an array, you can just use array_diff to find the words that are not already in the second array, then to add them to the second array, just use array_merge. There's no need to loop.

The dot . was there for a specific purpose (it makes the cookie match all sub-domains of the domain.) Do you have php's error_reporting set to E_ALL and either display_errors set to ON or log_errors set to ON for your live server so that php would report and display or log all the errors it detects?

utf8_encode is not needed because all the characters are plain ASCII characters - the characters 0-9a-f.

You need the leading zero's so that the corresponding position in each string being compared has the same magnitude in the two strings (i.e. you are trying to compare the two year-thoushands characters in each string together all the way down to the two day-ones characters in each string together...) See this post - http://www.phpfreaks.com/forums/index.php?topic=345557.msg1631267#msg1631267

You are likely missing quotes around the value attribute in your HTML - value = 'toyota - japan' or value = "toyota - japan"

What's the actual value are you putting into the query for the pay? What is your pay column definition?

We could tell you more about the security of your login script by seeing the code for both the login form processing script (everything but your actual database connection username/password) and the code you use to test and restrict access on a protected page.

In your previous thread on this subject, you removed the md5() hashing because your password field was not long enough to hold an md5 value and the test password you have stored was in plain test anyway. Have you correct these things, because until you do, code that uses a md5 value of the entered password won't ever match anything?

The - 'User ID and Password not found' message means that the query executed without any errors but it didn't match any rows in the database. You would need to troubleshoot why the query is not matching any row in the table. Unfortunately, that book/code is not doing you any favors toward learning to write code that is secure and easy to troubleshoot. Add the following line of code, right before the $query = "... ... ..."; statement - $pwd = md5($_POST['password']); Then, right after the query = ... statement, echo both the $pwd variable and the $query variable so that you can see what the md5 value of the password is and what the actual query statement is. If the query statement contains the correct values for both the $_POST['user_name'] and the $_POST['password'] values, you will need to check directly in the database table if you have a row with a matching user_name and a password value that matches the md5 value that you echoed in the $pwd variable. Make sure that the length and every character of the echoed md5 value matches what is stored in the password field in the database table.

It's your query that is ordering the data, therefore the data itself must be trimmed for the ORDER BY term in the query to be able to order all of it correctly. Doing this in php code would only be useful if you were selecting the data, looping through it, then updating the table with the trimmed result, which as already mentioned, is not needed. You can directly UPDATE the table with the trimmed result in one UPDATE query.

... and you might want to do this in your query, if your intent is to UPDATE the data with the trimmed value - http://dev.mysql.com/doc/refman/5.5/en/string-functions.html#function_trim No need to select data, loop through it, and update it. Just UPDATE it all at once with the trimmed value.

You can use mysql's DATE_FORMAT() function in your queries to retrieve the YYYY-MM-DD format into any format that you need. You can also use mysql's STR_TO_DATE() function in your queries to convert any formatted date into a YYYY-MM-DD format when you insert/update data or provide literal dates to be used in queries. Once you have converted your existing values in your database table(s) (it can be done by adding a DATE column, using a single UPDATE query to populate the DATE column from your existing values, then removing the varchar column), other than changing your query statements to use DATE_FORMAT/STR_TO_DATE, you don't need to make any other changes.

If you search the forum for the phrase - 'isn't working', you will find that means absolutely nothing to us, because we are not standing right next to you and don't know what you saw or what you expected to see. For any specific code or even one changed line in some code, there can be a dozen different symptoms, and for any symptom there can be a dozen different things that might causing that symptom. In programming, there's not a magical one to one relationship between 'isn't working' and what is causing the problem. To get help with your code, you must post enough of your code the duplicates the problem, a statement (or picture) of the actual symptoms you saw in front of you that leads you to believe that your code isn't working, and a statement of what the actual expected result should have been. If you are getting a blank page in your browser, you also need to do a 'view source' of the page and post information about what you saw in the view source.

Read the post at the following link for why you cannot do greater-than/less-than comparisons on dates unless they are in the correct format - http://www.phpfreaks.com/forums/index.php?topic=345557.msg1631267#msg1631267 You must store dates in your database using a DATE data type (that's what it is for) and do comparisons between dates that all have the same YYYY-MM-DD format.

You are likely getting an error that would help pin point the cause of the problem. Add the following three lines of code, immediately after your first opening <?php tag, before any session_start statement, and see what if any errors are reported - ini_set("display_startup_errors", "1"); ini_set("display_errors", "1"); error_reporting(-1);

The reason you have a little more than 1 page of data that is out of alphabetically order and comes before the rest is because that data has some white-space characters (looks some with 1 and some with 2 space characters in the 'view source') at the start of each value and the ORDER BY places those rows first. You need to trim the data, at least in the name column, in your database table, so that the ORDER BY will produce the correct results.

Only if you modified the display code to be specific to your table column(s.) Do you have php's error_reporting set to E_ALL so that all the php detected errors will be reported? Beyond that, you would need to post your usage.php code that you modified to use with your database table.

In its simplest form, to make a dynamically produced php page, you place all the php 'business' logic as the first thing on the page. The php code determines what the page should contain and produces the content that you want (in php variables.) Then you output the content by simply echoing each php variable where you want each piece of content to be on the page. For something like the login/register/logged-in section on the page and the specific menus/navigation that change depending on if you are logged in or logged out, the php code would produce the correct content for those regions and then simply output/echo the content at the correct point in the HTML markup of the page layout. More specifically, if the current visitor is not logged in, the login form and registration link would be produced by the logic. If the current visitor is logged in, his username and log out link would be produced and all the navigation specific to a logged in person would be produced. If the login form is submitted, the form submits to the same page (read the next paragraph for how that would be handled in the logic.) If the submitted username/password is correct, the user is marked as being logged in and the remainder of the php logic produces the correct content for a logged in user. If the registration link is clicked, the page produces the necessary output needed for the registration process. This forum software (SMF) uses what is referred to as a page controller (google for that to find what it is and for the many code examples of the different ways, simple to complex, of implementing it), where there is one index.php page and an action= attribute on the end of the URL. The php logic on the page uses the action= value to determine what the page should do.