Leaderboard

Sorry, I was thinking UPDATE not INSERT.

this problem goes away if you switch to the much simpler and more consistent PDO extension, because you can fetch data from a PDO prepared query exactly the same way that you fetch it from a traditional, non-prepared query. a PDO prepared query also uses ? for the place-holders, so you can reuse your existing sql query syntax. all you have to do is make the connection using the PDO extension (setting the character set to match your database tables, set the error mode to exceptions, set emulated prepared queries to false, and set the default fetch mode to assoc), which i'm pretty sure has already been posted in some of your threads, but which someone would be willing to re0post, then change the remaining mysqli statements to the equivalent PDO statements, which you can do using by rote/A-B pattern matching. the statements needed for binding input and output parameters also go away. you simply supply an array of the input values to the execute([...]) call and use one of the fetch statements to retrieve the data. yes. you should be internalizing the meaning of the php, sql, html, and css statements/words you are using so that you know what they actually do, so that when you read or write code you know what each statement/word contributes to the 'story' on the web page. you basically need to become fluent enough in each of those languages so that you can write a meaningful and understandable short story using them. when i/we read code that someone posts, we start at the top and actually read the statements/words that have been posted, adding up what the meaning of each statement/word is contributing to the story being told. when we get to the end, if the statements/words all made sense and all have something to do with the task at hand, we know that the code will probably work (through testing will determine if it actually does.) when we see code that has all kinds of unnecessary, repetitive, missing, misused, and out of order statements/words, what do you think pops into our minds? as to your posted code - you are no longer requiring (you should use 'require', not 'include', and both of these are not 'functions' so don't put ( ) around the filename) either the connection or the error .php files. Instead, you have attempted to insert the code into the main file, introducing errors in the code and adding repetitive logic. why did you change this? did you miss the point about putting common code into a .php file and requiring it when needed? php's error related settings should be put into the php.ini on your system. this is so that they will report ALL php detected errors, even parse/syntax errors. this also allows your development system and your live/public server to be configured with their own error related settings and you don't need to remember to edit any code when moving it between those two systems. when you were initially and most lately given the mysqli_report(MYSQLI_REPORT_ERROR|MYSQLI_REPORT_STRICT); line, you were told and shown to put it before the line where you make the database connection. that would mean that it belongs in the conn.php file. if you had put it there and left it there, you wouldn't be mucking around with it now. you have also been told a number of times that when using exceptions for database statement errors, which is what the mysqli_report() line of code does, that none of the connection, query, prepare, and execute error handling logic will get executed upon an error and all that existing logic should be removed, simplifying and de-cluttering the code. you were also told that using exceptions for database statement errors and letting php catch and handle the exception, meaning there is no try/catch logic in your code, will cause database statement errors to 'automatically' get displayed/logged the same as php errors. you are now asking in the conn.php code how to cause a connection error to get displayed/logged. you have been told how to do this. you also don't display these errors to the user/visitor to your site. you only display these errors to the programmer/developer, i.e. you, when you are learning, developing, and debugging code/query(ies.) you don't even tell the visitor, which could be a hacker, anything about an error that has occurred, since that will just encourage them to do more of the same things that caused the error in the first place. you are putting unnecessary double-quotes around php variables in the conn.php code. again, what do you think pops into our minds when we have to look at unnecessary things that could be causing a problem when someone asks us to look at their code? you have both a die() and an exit() statement in the conn.php code. that do the same thing. are you even looking at and reading your code? the search form should use method='get' (which is the default if you leave the method attribute out.) get is used when determine what will be displayed on a page. post is used when creating/altering data on the server or performing an action, such as sending an email. an empty action='' attribute is not valid html5. you were actually told to remove the entire action attribute. the search form should be 'sticky' and re-populate/select the form field values/choice(s) that correspond to any submitted data. only <input ... > or <button ... > tags that have a type='submit' attribute are capable of submitting the form. use one or the other, not both. only form elements with a name='...' attribute will be included in the submitted data. if you have only one post method form on a page, after you have tested the server REQUEST_METHOD, that's all the logic you need to start the form processing code. except for unchecked/unselected form elements, all other form fields will be set once the form has been submitted. using isset() around always-set form fields is a waste of your typing time. your form processing code should trim, then validate all inputs, storing any validation error messages in an array, using the field name as the array index. if after the end of the validation logic the array holding the error messages is empty, you can use the submitted form data. the get method 'business' logic, that knows how to get/produce the data needed to display the dynamic content on the page should come before the start of the html document. you would fetch all the data from any query into a php variable, then test/loop over that variable at the correct point in the html document. if you are going to continue to use the mysqli extension, just use the single $stmt = mysqli_prepare($conn,$query); statement, instead of $stmt = mysqli_stmt_init($conn); and mysqli_stmt_prepare($stmt,$query). i'm pretty sure you have been told this point before. i don't know why you are using the most complicated way of doing things. remember these two acronyms - Don't Repeat Yourself (DRY) and Keep It Simple stupid (KISS.) if you find yourself repeating the same code over and over or doing something in the most complicated way possible, you are probably doing something wrong. don't do this - if($bind_result === FALSE) the rest of the mysqli stmt error logic you have... the mysqli_stmt_bind_result() statement will produce a php error if it fails, which would be due to a programming mistake on your part. it won't produce a database statement error, and you won't get anything useful from the current code. the only things that produce database statement errors/error numbers are the connection, query, prepare, and execute statements. don't do this are well - if($stmt_fetch === FALSE) the rest of the mysqli stmt error logic you have... there's two problems with this - 1) your code is fetching the 1st row from the result set, but not displaying it, so you will be missing a row of data, and 2) a false value when you fetch data only means that there was no data to fetch. this is not an ERROR, it's how your code knows to stop fetching data. there won't be any mysqli statement error/error number values to display. php will destroy all resources when the script ends, so in most cases, you don't need to close a prepared query statement or close the database connection. most of these things will actually simplify and clean up your code, leaving you with just the implementation logic that you should be concentrating on to get the application to work and the forum members will be more happy about looking at what you are posting since it won't contain a wall of unnecessary elements.

INSERT queries don't have WHERE clauses. they have a list of columns and corresponding values. you would add the user_id column next to the date column and supply the user id value for that column when the query gets executed. you should not put external, unknown, dynamic values directly into a query. use a prepared query. here's the insert query documentation definition with the most commonly used elements highlighted - the value_list definition - for a prepared query, the value_list would contain a ? place-holder for each value.