Leaderboard

the error response you are getting has nothing directly to do with checkbox form data. you are getting an error with either the sql query statement or the execution of the sql query, but because the error handling does not display/log the raw error information, you don't have any idea why it is failing. you need to find what the problem is and correct it. just trying a bunch of different things results in a lot of wasted time, with no actual learning occurring. the current code is using the PDO extension, a prepared query with external, unknown, dynamic values, is supplying an array of the inputs to the execute() call, and is using exceptions for errors. this is the best choice for performing database operations and you should continue to use these practices. some changes for the current code - when you make the connection, set emulated prepared queries to false, i.e. you want to run real prepared queries. set the default fetch mode to assoc, so that you don't need to specify it in each fetch statement. i would also name the connection variable $pdo, so that anyone looking at the code can tell what database extension it is using. because you are using exceptions for errors, there's no point in having discrete conditional error handling logic in your code, because it will never get executed upon an error. so, simply remove the if($result)... logic. if duplicate data is not an application error for this insert (and also for an update) query, you would NOT have any exception try/catch code at all, and simply let php catch the exception, where php will use its error related setting to control what happens with the actual error information (database statement errors will 'automatically' get displayed/logged the same as php errors.) for what you are currently experimenting with, this is probably the case. if you remove the try/catch code you have now, and assuming that your php is configuration to report and display all php errors, you will now start seeing database statement errors too. if this insert (and also for an update) query could result in duplicate data values and this is an error for your application, you would catch the exception in your code, test if the error number is for a duplicate index error, and setup a message for the user telling them what was wrong with the data they submitted. if the error number is for anything else, re-throw the exception and let php handle it. note: $_POST is always set, even if it is empty, so the current logic testing if(isset($_POST)){ will always true. also, don't copy variables to other variables for nothing, this is just a waste of your time typing all of that. your post method form processing code and form code should - detect if a post method form was submitted. keep the form data as an array variable, then operate on elements in this array variable throughout the rest of the code. trim all the input data at once. by keeping the data in an array variable, you can do this with one single line of code. validate all the inputs, storing validation errors in an array, using the field name as the array index. after the end of all the validation code, if the array holding the errors is empty, use the submitted form data. after using the submitted form date (which could cause user/validation errors in itself), if there are no errors, execute a redirect to the exact same url of the current page to cause a get request for that page. if you want to display a one-time success message, store it in a session variable, then test, display, and clear that session variable at the appropriate location in the html document. to allow the user to go to a different page, provide navigation links. if there are errors at step #6, the code would continue on to display the html document, where you would test and display the contents of the array holding the errors, then display the form, populating the form field values with any existing data. apply htmlentities to any values you output on a web page to help prevent cross site scripting.

But if you validate and then redirect, then the page at the end of that redirection must repeat the validation, otherwise someone could send data to it directly, bypassing the validation. The basic pattern for my pages is something like this: if ( form data submitted ) { Validate form data - populate variables and error messages ; if ( form data valid ) perform any required Action ; } Display Form, with values and/or error messages and/or results from the Action. Any "validation" that you do in Javascript on the client is for the Users' convenience only - you must not rely upon it because nothing that comes from the client can be trusted. (For example, do you validate the form value submitted from the HTML "select" list that you sent? You probably should ...) Regards, Phill W.

If I were a customer, I wouldn't want to remove an item and then end up paying for it because the programmer couldn't be bothered to recalculate.