PFMaBiSmAd

Did you refresh the form page in your browser so that the change in form was in effect?

You are not validating the data being put into your query. Anytime $args[0] is empty or non-numeric, your query will fail, which will cause any code that expects $catsql to be a result resource to also fail and produce an error. You need to validate $args[0] to make sure it contains something and contains a number (or cast it as a number.) To troubleshoot this, you would need to find out what is actually being supplied in the function call to get_category_name, then either find and fix what is allowing the function to be called with a value that is not expected.

Yes, disabled form fields are not submitted. If you want to display the value, you should either just echo it somewhere or if you want it to appear in a disabled form field, you will need to duplicate it in a hidden field (or pass it as a get parameter on the end of the URL in the action="..." attribute.)

The id only has meaning in the browser. As far as php is concerned, only the name has significance.

You were already told what is causing the error and how to troubleshoot it -

I was being a bit more literal when asking what your code for the form and the form processing was. We can assume what your code is attempting to do. However, what it is actually doing is not working and no one can help with what it is doing without seeing it. If the form is valid HTML and it is submitting all the data you expect, nothing php does will overwrite the data (unless register_globals are on, which since they were turned off by default over 8 years ago should not be a factor) and it is highly likely that either the data is not being submitted by the form or your code is doing something to overwrite the missing data or is not using the correct variables where the data is at.

Turning on magic_quotes_gpc is not a fix because it has been completely removed in upcoming php6. You are going to need to find what is causing the actual problem. Also, magic_quotes_gpc does not affect the upload data (it could be affecting what you see when you echo/print_r things to your browser if there are any quotes in the form field names or file names.) And php has had some bugs concerning magic_quotes_gpc in their efforts in php5.3.x getting ready to remove it. What php version are you using?

You either have a logic error that is clearing the $_POST array (edit: or a logic error that is attempting to access the $_POST variables at a point in time when they are not set) or your form's HTML is invalid or you are exceeding the post_max_size setting or the Suhosin hardened php patch is installed on your server (though I think it just cuts off variables after x amount.) What is your code that is producing the form and your form processing code? What is an estimate of the total size of the form data v.s. what a phpinfo() statement shows for the the post_max_size setting? Does you server have the Suhosin hardened php patch? Does this work for a smaller amount of data?

The error means that your query failed to execute and returned a FALSE value. If you echo mysql_error() on the next line after the mysql_query() statement, it will tell you what error occurred. I'm going to guess that your table is named Score and not score and that you are doing this on an operating system that is case-sensitive. Is there some reason you are not using an INSERT ... ON DUPLICATE KEY UPDATE ... query - http://dev.mysql.com/doc/refman/5.0/en/insert-on-duplicate.html

Having the array keys but no values for the $_FILES array is abnormal. Ether the whole $_FILES array will be empty (you exceeded the post max size setting) OR the key(s) will exist and you will have ['name'], ['error'], ... elements present, even if those elements are empty. You either have a logic error in your code that is overwriting the values under certain conditions or the web server/php is overwriting the values under certain conditions (i.e. the server has the Suhosin hardened php patch installed, register_globals are on, or the php installation is messed up.) As MrAdam replied, you can always get faster solutions to your problems in a help forum when you post all the relevant code so that the code can either be eliminated as the cause of the problem or someone can see what the code is doing that is causing the problem.

$PHP_SELF was depreciated and should have been turned off by default in php4.2 in April of the year 2002 when register_globals were turned off by default. As a temporary patch you could turn register_globals on (assuming your web host allows it) but since register_globals have been completely removed in php6, you will need to fix your code sooner or later. It should be $_SERVER['PHP_SELF'] Register_globals magically populated program variables (such as $PHP_SELF) from the corresponding predefined superglobals where the data actually originates. Unfortunately, register_globals also allowed hackers to 'magically' set session and program variables by simply setting a same name external post/get/cookie variable and a lot of web sites were taken over. If your code is using any of the following source variables, you need to modify your code to use the actual $_XXXXXX superglobal variable instead of a program variable by the same name as the superglobal index name - $_SERVER — Server and execution environment information $_GET — HTTP GET variables $_POST — HTTP POST variables $_FILES — HTTP File Upload variables $_SESSION — Session variables $_ENV — Environment variables $_COOKIE — HTTP Cookies

Yes, as long as each one is listening on a different port number.

No, you didn't -

What value do you want the variables to have when there is a NULL? Just add an else{} clause to the if(isset()){} statement and assign the value you want or you can probably just remove the if(isset()){} test.

A header() statement JUST sends a header to the browser. It has no affect on the php script, which continues execution after the header() statement until it gets to the end of the file or an exit/die statement.

When you do a left join and there are no matching results on the right hand side, NULLs are used for values. You are getting NULL values (test by using var_dump() on each value.) Php does not consider a NULL value to be set and your isset() code is being skipped (just tested.)

Web servers are not designed to do what you are trying to do. Even if you get it to work on your current web server/php/browser combination, there is a good chance that it will stop working when either of those three things are changed, due to all the buffering and compression that goes on (your current problem could be due to something at your end of the connection, such as a proxy server your ISP is using on your connection.) If you want to output discrete pieces of information and have each of them displayed 'real time', you must use AJAX to periodically make http requests to a web page and have that page output the current information.

That code is really way out of date. It uses $HTTP_POST_VARS instead of $_POST. $HTTP_POST_VARS were depreciated in php4.1 (10-Dec-2001) when $_POST was introduced, turned off by default in php5, finally throws a depreciated error when turned on in php5.3, and have been completely removed in php6. Change the following line from - $paypal_info = $HTTP_POST_VARS; to - $paypal_info = $_POST; You should probably also change the short open tag <? to <?php

$semister_year = $bcinfo1[0]['semister_year'][2] . $bcinfo1[0]['semister_year'][3];

The error has nothing to do with the php code. It is likely your form is using the get method, rather than the post method. What is your form code?

The code you are executing to create the table does not have any code in it to make a connection to the database server first.

Are you debugging this code on a system with error_reporting set to E_ALL and display_errors set to ON in your master php.ini so that ALL the errors php detects will be reported and displayed?

You need exit; statements after every header redirect to prevent the remainder of the code on the page from being executed while the browser is requesting the URL that is the target of the header() redirect.

Use the mysql DATE_FORMAT() function in your query to return a DATE value formatted any way you want - http://dev.mysql.com/doc/refman/5.0/en/date-and-time-functions.html#function_date-format

When you put a local php.ini it is apparently only setting the values from the local php.ini and using php's default values for everything else. You will either need to make a local php.ini that has all the necessary values or you will need to correct your code so that it works regardless of the settings. Since you have not shown the index.php code that is including your other code, it is not clear what php setting is causing your database connect code to not work (I previously mentioned which setting is related to the first two error messages.) What are the current error messages?