mac_gyver

MySql (with whatever variations in capitalization you like) is the database server type. mysqli and PDO are php's extensions that allow your php code to communicate with the database server. if you understand what your mysqli based code is doing, you should be able to convert the code. all it's doing is - building an sql query statement. which should be in a php variable, in order to separate the sql as much as possible from the php, and allow you to separate the common php code used or in this case change the database extension being used. there's no difference between the sql query statement for the mysqli or PDO extensions, when using positional ? prepared query place-holders. prepare the sql query. there's no difference in the php syntax for the the mysqli or PDO extensions, except that the connection variable must be (and is usually named) for the extension being used. bind input data/execute the prepared query. If you are using php8.1 or higher, the php syntax for the execute statement is exactly the same. you can then use msyqli's get_result() and fetch_all() methods to fetch all the data from the result set.

you are not seeing the new record until you add another one, because the overall code on your page is out of order. you are processing the post method form data after the point where you are querying for and displaying the data on the page. did you read my reply at the end of your previous thread? as to the data being repeated, when you examine the raw data in the database table are there duplicates?

the OP's 'working' database code is using the mysqli extension. the provided autosuggest example is using the PDO extension, along with a connection variable name, $pdo, hinting at what database extension it is using. i recommend that you convert your existing database specific code to use the much simpler and better designed PDO extension.

you would use a typeahead/autocomplete/autosuggest input field, using ajax to get a list of matching people, that the user can then click on one to select it.

you should have a category table, with id and name columns. this would define the different categories of items. the item table would have id, category_id, name, description, and any other columns needed to define each item. to display the category menu you would query the category table to get the category data that you want in the order that you want it, then loop over the result of this query to produce the category menu. if someone clicks on one of the category menu links, the category id in the link would be used to query for and display the items matching that category.

I'm gusseting the posted picture is after you have submitted the form? after you set php's error_reporting to E_ALL and display_errors to ON, you should find the reason for that problem. here are a ton of coding practices that will help organize and simplify the code - the code for any page should be laid out in this general order - initialization post method form processing get method business logic - get/produce data needed to display the page html document some specific points for the posted code - use 'require' for things your code must have. include/require are not functions. the () around the path/filename don't do anything and should be left out. don't echo large amounts of static html. drop out of php mode and put the html inline. if you use php's short open-echo tag and a closing tag around a value, you can output variables in the html document using <?=$var?> don't escape double-quotes inside a php double-quoted string. simply use single-quotes inside the string. don't unnecessarily switch out of and back into php mode. just stay in php mode. don't use post method forms for navigation. use href/links. your markup is out of date. you need to validate the resulting web pages at validator.w3.org because this entire page requires the current user to be an administrator, preform the user level test once, near the top of the code and take an appropriate action if the user isn't an administrator. to get a form to submit to the same page it is on, simply leave out the entire action='...' attribute. you need to store the customer first and last names in separate columns. as a more advanced programming subject, if you have more than 2-3 form fields, you need to dynamically validate and process the form data and dynamically produce the form fields, instead of writing out code for every possible field. some points for the post method form processing code - don't attempt to detect if the submit button is set. there are cases where it won't be. instead, detect if a post method form was submitted. keep the form data as a set in a php array variable, such as $post or $data, then operate on elements in this array variable throughout the rest of the code. trim all the input data before validating it, mainly so that you can detect if all white-space characters were entered. once you do item #2 on this list, you can trim all the data using one line of code. validate all the now trimmed input data, storing user/validation errors in an array using the field name as the array index. after the end of the validation logic, if there are no errors, use the submitted form data. use a prepared query to prevent any sql special characters in value from being able to break the sql query syntax. if it seems like using the mysqli extension is overly complicated and inconsistent, it is. this would be a good time to switch to the much simpler and better designed PDO extension. if an insert/update query can produce duplicate data errors, you need to test for and handle this in the query exception handling for the query and setup a message for the user (add it to the array holding the user/validation errors) letting them know what was wrong with the data that they submitted. after using the submitted form data, if there are no errors, perform a redirect to the exact same URL of the current page to cause a get request for that page. this will prevent to browser from trying to resubmit the form data should that page get browsed back to or reloaded. to display a one-time success message, store it or a flag value in a session variable, then test for this session variable, display the message, and clear the session variable at the appropriate location in the html document. if there are errors, the code will continue on to redisplay the html document, where you will test for an display any errors, either all at once or individually adjacent to the field they correspond with, and populate the form fields with any existing data so that the user doesn't need to keep reentering values over and over. any dynamic value you output in a html context needs to have htmlentities() applied to it to help prevent cross site scripting.

you would ORDER BY the id (autoincrement primary index) column instead. a DELETE query has the same ORDER BY and LIMIT terms as a SELECT query.

The closing </option> tag on the $ThisYear output is missing the closing >, so the following markup is broken. check the 'view source' of the output in your browser.

do you have php's error_reporting and display_errors set so that php will help you by reporting and displaying all the errors it detects? error_reporting should always be set to E_ALL. on a live server, you can temporarily set display_errors to ON to get immediate feedback as to any problems. these settings should be in the php.ini on your system, but can temporarily be put in your php code, right after the first opening <?php tag. if php's output_buffering setting is on (another bad decision by php), you can have output before a header() statement and the header() will work. you should check using a phpinfo() statement to see what this setting is, as it also hides non-fatal php errors and any debugging output from your code. a full URL is not a problem. however, if the protocol changed, e.g. from https to http, the session won't match, because session cookies are kept per protocol. you are doing this on live web hosting? have you set your session_save_path to be to a location within your hosting directory tree, outside of/below the htdocs folder, so that all the session garbage collection by all the other hosting accounts isn't deleting your session data files? if your session data files are in the default tmp folder with all the other accounts, the shortest session.gc_maxlifetime of all those accounts is what will affect your session data files. the only user data you should store in a session variable upon login is the user id (autoincrement primary index.) you should query on each page request to get any other user data, such as a username, permissions, ... this is so that any changes made to this other user data will take effect on the very next page request after they have been changed. do you really want a situation where you have demoted or banned a user and they can continue to visit your web site because their session data says they can? and is this inside of code testing if a post method form has requested the page, so that it won't get executed just because a browser/client has made a get request to the page? browser's are now doing things like pre-requesting pages that are in your browser's search history when you start typing things in the address bar. also, a session can hold data other then who the logged in user is. you should only unset those session variable(s) that are specific to the logged in user. the code you have shown has the form processing code and the form on separate pages, with a bunch of extra redirects. this results in nearly 2x the amount of code, provides a bad User eXperience (UX), and depending on how you are getting data/messages back to the form, is open to phishing attacks and cross site scripting. the only redirects you should have in your application code are upon successful completion of post method form process and they should be to the exact same URL of the current page to cause a get request for that page. this will prevent the browser from trying to resubmit the form data should that page get browsed back to or reloaded, where someone can use the browser's developer tools to see what the form data, such as the password, is. the code for any form and related form processing should be on the same page. the code for any page should be laid out in this general order - initialization post method form processing get method business logic - get/produce data needed to display the page html document

the code's looping until there's an error (while no error). just use a foreach loop, with a break when the error occurs OR perhaps loop over all the data, producing an array of errors, then use the array of errors after the end of the loop? what does a sample of the data look like, what exactly are you doing with it, what do you want to do upon the first error or do you want to check every entry for errors?

the code that's responsible for populating the $user variable needs to setup a default value if there is no user. the code testing the value then only needs to be concerned with what the value is. also, at that point, you are only dealing with a true or false boolean value. you should test for the true case, e.g. if($user){ // there is a user} else { // there is not a user}

two problems - 1) you don't have php's error_reporting set to E_ALL (it should always be this value) and display_errors set to ON, preferably in the php.ini on your system, so that php will help you by reporting and displaying all the errors it detects, and 2) once you do that, you will get a php error about the 1st argument being a string instead of a datetime (Interface/immutable) object. to use date_format() you must first create a datetime object from the fetched value - $DD = new datetime($row["OrderDate"]); echo $FormattedDate = date_format($DD,'d-m-Y H:i');

one primary reason has already been given - any format where the fields are not from left to right in most significant to least significant order cannot be directly compared by magnitude. additional reasons for using a standard sgl data type for storing dates/datetimes are - it allows you to sort using the values (because date comparisons directly work on the values) it allows you to use all the built in sql date/time functions this standard format is also what php's date/datetime functions accept and use by default is uses the least amount of storage it results in the fastest queries you store and operate on dates/datetimes internally using this standard format. you only format values in your local format when you display them. if you have a lot of existing data stored in some other format, you can add a standard date or datetime data type column to your table, and use MySql's STR_TO_DATE(str,format) function in an UPDATE query to populate the new column from the existing values. once you have converted and tested your code to use the new column values, you can delete the old column from the table.

you need to use a DATETIME data type and store the values in a sql YYYY-MM-DD hh:mm:ss format (the equivalent php date() format specifier would be 'Y-m-d H:i:s') this will allow you to preform date comparisons directly on the values in the sql query statement. you would then use a WHERE clause in a query - WHERE your_datetime_column >= NOW() - INTERVAL 1 day to match records that are within one day of the current date. edit: supplying a a value that 'looks' like the list of parameters to a function call doesn't work. this is treating the whole value as the 1st parameter (hour) or is possibly producing a php error.

learning involves forming a theory about how something works, performing an experiment to prove or disprove the theory, observing the result of the experiment and concluding if the theory was correct or not. you will learn much better and quicker if you make an attempt at designing, writing, and testing code to see if it does what you expect. if(loggedin()) { // code for all logged in users if($user_level == 1) { // code for a logged in user with level == 1 } else { // code for a logged in user with level != 1 } } else { // code for a non-logged in user } i recommend two things - 1) use defined constants, such as define('ADMIN_USER',1);, instead of literal numbers, so that anyone reading the code can tell what the numerical values mean, 2) when conditional 'failure' code is shorter then the 'success' code, invert/complement the condition being tested and put the shorter code first. this will make your code easier to read and understand.