PFMaBiSmAd

It's also possible that you are examining information in one database but the backup is being restored to a different one. Perhaps you have one database named ABC and one named abc. These would not be the same databases on an operating system that is filename-case-sensitive.

You need to use both of the following lines of code to insure that errors are both reported and displayed - ini_set("display_errors", "1"); error_reporting(E_ALL); Every header() redirect needs an exit; statement after it to PREVENT the remainder of the code on the page from being executed. Your validation code might in fact be sending a header() redirect due to a validation error but because the code continues executing and is reaching the header() redirect to '/booking/success' it is likely that you are only seeing that result of that one.

Did this backup come from the same system and same mysql version you are trying to restore it on? Have you opened this backup file using an editor of any kind, even if you only viewed the contents in it or did you specifically make any changes in the file? What does the backup file have in it starting a few lines before the table definition that is not working and what does it have as the table name/table definition at the point where it is not working? I am thinking you have some special/invalid character(s) as part of the table name. You could also have some SQL code as part of your data in a column but it did not get properly quoted in the backup and it is breaking the SQL syntax during the restore operation. Short-answer: You need to post actual information about what is specifically not working so that someone could see if it contains something that could cause the symptoms you are getting. In computers and programming, due to their general purpose nature, there is not a "one symptom/error" equals "only one specific cause" relationship. The same symptom or error can be caused by a dozen different things and it takes seeing what you are actually doing or what your data is in order to eliminate which of the possible reasons are not causing the problem and to narrow down the reasons that could be causing the problem.

Or you can use methods that are similar to how you would do it in C/C++ - http://www.phpfreaks.com/forums/index.php/topic,273584.msg1292539.html#msg1292539

All data (content) that comes from an external source that is being output on a web page needs this - http://www.phpfreaks.com/forums/index.php/topic,274065.msg1295197.html#msg1295197 to prevent any HTML/CSS/Javascript in it from being rendered as HTML/CSS/Javascript

UPDATE your_table SET your_column = REPLACE(your_column,' ','')

Once you start debugging your code on a system with error_reporting set to E_ALL and display_errors set to ON, you will find that your date and comment fields in your form don't have the correct name="..." attributes.

What does happen in the browser when you submit the form? Does it just redisplay the form or does it redirect to index.php? For debugging purposes, please add the following two lines of code immediately after your first opening <?php tag - ini_set("display_errors", "1"); error_reporting(E_ALL); FYI, the extra semicolon ; on the end of the query statement would normally be used when you execute the query directly against the mysql server, but it is optional when executing a query through php. It is not a php or an sql error.

For debugging, I would recommend echoing your $query variables to see exactly what is in them. The only apparent problem is that leading zeros on numbers in php make them octal values, so it is likely your $date tests are not producing the results you expect. I would put some quotes around the values on the right-side of the == comparisons so that what is in $date will match them.

Without mysql_real_escape_string() to protect against sql injection, a hacker can easily dump all the information in your tables. This would give him information about usernames and assuming you are not hashing your passwords, it would directly give him those and if you are hashing your passwords but are not using a 'salt' string, he could easily determine commonly used passwords. Your user login system could also not be actually preventing access to the forms and form processing code. Edit: and if your login system is just what you posted in the other thread, where if the $_POST['name'] value is not in your banned table you allow a post to be INSERTED, that is not going to stop anybody. All they need to do is use any name that has not yet been banned.

Start by debugging the first form (the code at the end of what you posted.) Do a "view source" in your browser and check if it is producing what you expect. It appears that you are putting one opening <form ...> tag before the while() loop, then putting repeated section with a hidden field for the class_id, the submit button, and a closing </form> tag. You would need to use different names for each hidden class_id field (with the same name, only the last value in the <form></form> will be used) and if you actually intend to make each table row its' own form, you would need to get the opening and closing <form></form> tags matched up. If you intended that there be a single form, then you would need to put a single closing </form> tag after the end of the while() loop. Short-answer: Start at the first step and make sure it is doing what you expect and submitting the data you expect, then go onto the next step that uses the data from the first step.

And why do you have two separate sets of code in that one script connecting to the database? If you compare what each set of mysql funcitons is doing, you will see why the one you are currently having a problem with is not working.

To display data on a web page that contains characters that have significance in HTML, you need to use htmlentities on the data when you output it to prevent the special characters in it from breaking the HTML on your page. Also, if you are outputting this data in a value="..." attribute in a form field, you need to surround it in quotes to make valid HTML.

Most of your page is within a HTML comment. From validator.w3.org - All the markup errors - http://validator.w3.org/check?uri=http%3A%2F%2Fwww.tastygrilling.com%2F&charset=%28detect+automatically%29doctype=Inline&group=0 Fix your HTML validation errors and your page will likely work in all browsers.

It would really help if you posted your code that is displaying the results and post an example of some values that don't work as expected. It is fairly likely that on the system where your code appears to work that the files are already in the order you expect and your code is not actually doing what you think it is.

The second method generally produces fewer syntax errors because there are fewer transitions between different syntax elements to keep track of. It is easier to see the syntax of what you are trying to produce, a quoted string, when you really only have one quoted string to look at.

The error message states where the output is occurring at that is preventing the headers from working. You must find what is causing the output and prevent it or send it after any headers.

You are likely on an operating system that is case-sensitive and the column names are case-sensitive too. The real column name is probably ID, or Id ...

Yes, a GET parameter only has meaning and only works on the end of the URL, not on the end of a file name.

The result is due to what the query operates on. The solution is either to use a correct definition for the column or force the query to treat the values as integers in the query. Using intval() or any other php code would not affect what the query does and would not work.

Post what you tried. xxxxxx out any sensitive information in the URL, but don't change any of the syntax. Also, does file.php use sessions or cookies to allow access to it?

Anything else would need a back-tick.

Because the table name contains special characters that are not normally permitted in an identifier and it starts with a number, back-ticks would be required. However, since your table name appears to be some form of an id (from $guid) you likely have a serious design flaw.

Yes, <?php will always work as an opening php tag. <? won't always work because it can be disabled and you won't always be on a server where you will have the ability to enable it. Don't use <? because it results in code that won't always be seen as php code.