PFMaBiSmAd

You must set the error_reporting/display_errors settings before your script is requested in order to show fatal parse errors. Since your script is never executed, the settings will never be changed when placed in your script. In addition to the problem that zeodragonzord posted (must be fixed in 4 places) there is a missing ) on one of the If() statements. You need to set the error_reporting/display_errors settings in your master php.ini. You will save a TON of time. Stop and start your server to get any change made to the php.ini to take effect.

There's nothing technically wrong what you have shown and the simplified example works (after you fix the few syntax errors in it.) Best guess is that the include statement is failing or the use of the short open tags is causing the code to not be seen as php code or you have a spelling error between the names being used... Are you debugging this on a system with error_reporting set to E_ALL and display_errors is set to ON so that php would report and display all the errors it detects? You would need to show the actual code and the actual error (the file and line number helps track down what is happening) to get the quickest solution without wasting a lot of time guessing which of the dozen possible reasons is causing the problem.

There's at least a dozen different things in the code you posted that could prevent the queries from being executed. Please narrow down the problem by describing the symptoms, errors, or result you are getting that leads you to believe that the queries don't work.

You should use a DECIMAL data type. Not if the definition was correct. You would need to post the definition you used if you want help with it.

You can start by telling us what that means. What are the symptoms? What do you see in front of you that makes you believe that the site goes down? What information is there in the server access and error logs? Do you have php's error_reporting set to E_ALL, log_errors set to ON so that all php detected errors would be logged to the error_log location?

Only if log_errors is ON, error_log has been setup, and error_reporting has been setup. All of these settings must be set before your script is requested in order to display fatal parse errors. You should be developing and debugging php code on a local development system anyway, at least past the point where you are experiencing fatal errors.

Fatal parse errors are the most common reason for blank pages (the second most common would be code that does not output anything.) You cannot set the error_reporting/display_errors settings in your code and display fatal parse errors because your code is never executed to change the settings.

No one here can help you when the code you post is not the code that exhibits the problem you want help with or when the code is a moving target.

Since the call does not have the third parameter ($connection), you are getting a fatal runtime error. Are you developing and debugging php code on a system with error_reporting set to E_ALL and display_errors set to on so that php would help you by displaying all the errors it detects. You will save a TON of time.

Nothing you posted shows the actual call being made to the login() function. You are including a file that presumable contains the function definition, but that is not calling the function.

Nope. Didn't work. And you should not be enabeling register_globals, even if your web host permits it. That has nothing to do with the error. The script you are trying to use is way out of date (8 years) and either should have been updated long ago or removed from distribution. You either need to update it so that it does not rely on register_globals or you need to find a more up to date script. Register_globals were disabled by default nearly 8 years ago becaue of the security hole they allow (hackers can easily set your session variables and a lot of web sites where taken over), finally throw a depreciated error in php5.3, and have been completely removed in php6.

number_format

You cannot use session variables to enforce these type of restrictions because all someone needs to do is drop the session id and they get a completely new set of chances. You must record and check the information in a database table.

It's likely that your session or the $context variable is not working and you would need to troubleshoot that problem first before you worry about getting a header() redirect to work. You also need an exit; statement after your header redirect to prevent the remainder of the code on the page from being executed. For all we know you have code on that page that is causing the current visitor to be logged out so when the code in main_page.php is executed it causes a redirect to the code you just did post. Edit: I guess I'll add that your redirect is somewhat backwards. You would normally only redirect as part of a log in script if the visitor that requested a page is not-logged in and you would stay on the requested page if the visitor is logged in. If the code on main_page.php is checking if the current visitor is logged in, but your session is not working, then yes you probably do have a redirect loop.

Based on just the naming being used (since you have not bothered to post the class definition), $storesDAO is likely a dynamically produced result object that references the result resource of a query. As has been stated twice before in this thread, there are some things that cannot be stored in a session - A possible solution would be to use a class destructor to take the data you need (assuming it is not actually a resource) and put it into session variable(s).

The default ORDER BY by is ASC. If the column is a mysql TIMESTAMP data type, what you are doing will work. What is the column definition and how did you produced and enter the values? Also, what is your code that is retrieving and displaying the results? Short-answer: There's nothing wrong with the method you are using and it should work, assuming the column, the data, and your code is what you are implying.

If the class definition exists before the session_start() statement, what you are doing should work. What is your code?

The md5() of an empty value is an MD5 value. You should validate the entered data first, then use md5() on the entered password.

Is there a session_start() statement on each page that sets or references a $_SESSION variable?

$HTTP_GET_VARS and $HTTP_POST_VARS were depreciated long ago (8 years), turned off by default in php5, finally throw a depreciated error in php5.3, and have been completely removed in php6. Use $_GET and $_POST

A logic error that could cause the symptom would be something like - if($_SESSION[....] = '') // sets the session variable to an empty string instead of - if($_SESSION[....] == '') // tests if the session variable is an empty string What does a phpinfo() statement show for the register_globals setting? If register_globals are on, it would also take having other variables (get, post, cookie, or program) with the same name as the session indexes to cause this problem. Frankly, it would take seeing all the relevant code that gets executed on both pages to be able to quickly see what the problem is. This could be due to a page being requested twice, redirect going to a page the redirects again due to a log in problem, a redirect that does not have an exit statement after it and the remainder of the code on the page is clearing the variables, you have a session_write_close statement before the variables are set and even though the print_r() shows them they are not actually part of the session variables, or a number of other things... that someone looking at your code could instantly pick out. Edit: Another possibility (assuming the code you posted for page2, up to the point where those session variables are being set it accurate) would be if page2 gets requested a second time either by your browser or through it being included or redirected to since it is not checking if the form was submitted before setting the session variables from the form data.

Because the array index names exist but the values are empty, it is likely that your code contains a logic error that is setting the values to an empty string. To pin down where in your code the problem is, where (start, end, or other) you are putting the print_r($_SESSION) statement in each of the two files? The problem is either after the print_r() in last file or before the print_r() in the page1 file.

A) Find the php.ini that php is using. A phpinfo(); statement in a .php file will tell you the php.ini that is being used as the Loaded Configuration File setting. B) Edit the php.ini and find and alter the the error_reporting and display_errors settings to the suggested values. C) Restart your web server to get any change made to the php.ini to take effect. D) Using a phpinfo(); statement in a .php file, confirm that the two settings were actually changed.

If the code you posted is all in one file, then every time that page is requested it will insert a row into the database (assuming that a query error does not occur.) So, when you browse to that page the first time, it will insert empty data. When the form is submitted it should insert the data from the form. That form processing code is too minimal. It is not checking that a form was submitted, it is not validating the data from the form, and it is not escaping the data being put into the query to prevent sql injection and to prevent the sql syntax from being broken should there be sql special character in the data. To start with, you should be learning php, developing php code, and debugging php code on a system with error_reporting set to E_ALL and display_errors set to ON in your master php.ini so that php will display all the errors it detects so that php will help you. You will save a ton of time. You also need to get into the habit of using error checking logic (check if something worked or not), error reporting/logging logic (output a useful message when something does not work and either log or immediately display (when in the debugging phase) relevant information about an error so that you can find and fix it), and error recovery logic (what action does your code take when an error occurs) in your code to get your code to tell you when something fails, why it failed, and to take an appropriate action in the program to recover from the error (such as not blindly performing follow-on actions that depend on data from a previous step.)

That's because the other values cannot be changed in a script. They affect what php does before your script is executed. Per the php.net documentation, they are settable - PHP_INI_PERDIR (or higher.) That means in a local php.ini (when php is running as an CGI application), in a .htaccess file (when php is running as an Apache Module), in the master php.ini (when you have access to it), or in the httpd.conf (Apache only and when you have access to it.)