mac_gyver

the mistake is probably at the binding/execution for the insert query. i won't mention what i saw because it is more important that you develop simple coding that will either work or it will tell you (display/log) why it isn't working. because you have no useful error handling for all the database statements that can fail (connection, query, prepare, and execute) and probably don't have php's error related settings set up to get php to help you, you are not getting any feedback that would allow you to solve the problem yourself. start by doing what was written here - https://forums.phpfreaks.com/topic/310992-mysqli-count-query-prepared-statements/?tab=comments#comment-1579137 next, this code is full of unnecessary things that don't add any value to what you are trying to accomplish (a form and form processing code that inserts data into a database table.) some recommendations that will result in simple code - put the form and the form processing code on the same page, with the form processing code above the start of the html document. this will allow you to directly display any validation errors and re-populate the form field values with the submitted data so that the user doesn't need to keep reentering the same things over and over. forget about that dumb test_input() function you found or were given. the only thing it is doing that's appropriate is trimming the data. everything else is either wrong for the context or needs to be conditionally applied. you should not test if the submit button isset. there are cases where it won't be. you should instead test if a post method form was submitted. don't write out line after line of code for each form field. just keep the set of form data as an array, then operate on elements in the array in the rest of the code. this will lead to dynamically validating and processing the submitted form data, further simplifying the code. validate all inputs separately, setting up a unique and helpful error message for each validation error, storing the validation errors in an array, using the form field name as the array index. this array is also an error flag. if there are no errors, it will be empty, and you can use the submitted form data. you can also test/display the contents of this array at the appropriate location in the html document. as has already been stated, your database definition must enforce unique entries. since it must do this to prevent duplicates, there's no good reason for the extra code/query to try to select the data first. just attempt to insert it, then detect if a duplicate key error occurred. this is also mentioned at the linked to forum reply. if you switch to the much simpler and more consistent PDO extension, over half of the database related statements will go away, which will eliminate the mistake i saw, because you don't have to produce multiple statements with things in them for each column in a query. in most cases, you don't need to close prepared statements or close database connections, since php will automatically do this for you when you script ends.

there are two main points for using a prepared query - to prevent sql special character in external, unknown, dynamic data values from breaking the sql query syntax. to speed up the overall process when executing the same query more than once within an instance of your script, since the communication and execution planning phase for the sql query statement is performed only once. if you are not doing either of these, don't use a papered query. when learning, developing, and debugging code/queries, you should display all php errors (when on a live/public server, you should log all php errors.) set php's error_reporting to E_ALL and display_errors to ON, in the php.ini on your system. if you put these settings into your code, parse/syntax errors wont be reported (the case of the missing } ) since your code never runs to change the settings for this type of error. putting these settings into your code also means more work for you later when you must find and change/remove them when moving the code to a live/public server. you also need error handling for all statements that can fail. for database statements, the easiest way of adding error handling, without adding logic at each statement that can fail (connection, query, prepare, and execute) is to use exceptions and in most cases let php catch the exception where it will use its error related settings (see above) to control what happens with the actual error information (database statement errors will 'automatically' get displayed/logged the same as php errors.) the exception to this rule is when inserting/updating duplicate or out of range user submitted values. in this case your code should catch the exception, detect if the error number is for something that your code is designed to handle, then setup a message for the user telling them what was wrong with the data that they submitted. for all other error numbers, just re-throw the exception and let php handle it. to enable exceptions for errors for the mysqli extension, add the following line of code before the point where you make the database connection, then remove any existing error handling logic, since it will no longer be executed if there is an error - mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

for this part of your question, it depends on the operating system. for a case-insensitive operating system, such as Windows, Hello.php and hello.php are the same. for a case-sensitive operating system, such as lunix, those are two different file names.

the warnings and notices are from php. they have nothing to do with with any framework the site is using for the presentation of information. the glob() is not matching any files and your code should test ( !empty($var) would work) before trying to access any of the results and output an appropriate message if no matching file was found. as to why the glob calls are failing, it would either be due to a problem with the spelling, capitalization, actual path being used, or there are no matching files inside the folders.

the posted code contains at least three places where it looks like characters were cut off from wherever this code was copied from, which would be producing fatal php parse/syntax errors. you should have the php error_reporting/display_errors settings in the php.ini on your system so that ALL php errors will get reported and displayed. putting these settings in your code won't help for parse/syntax errors since your code never runs to cause the settings to take effect. next, you have probably 5 times too many queries, code, and variables. some suggestions - use exceptions for database statement errors and in most cases let php catch the exceptions, where it will use its error related settings to control what happens with the actual error information. you can then remove all the error handling logic that you have now. INSERT queries don't have WHERE ... clauses. the account_number column should be added to the list of columns being inserted. don't put external, unknown, dynamic values directly into an sql query statement. use prepared queries. you would also want to switch to the much simpler PDO database extension. don't copy variables to other variables for no reason. you should NOT maintain a balance column in a single row by updating the value. any transaction that increases or decreases an amount should be handled by inserting a new row in the transactions table. the sets of INSERT queries that deducts the amount from the source account and adds the amount to the destination account need to be part of a database transaction, so that they will either both succeed and be committed or they will be rolled back. the post method form processing code should be before the start of the html document and should store any validation error messages in an array, then test/display the contents of this array at the appropriate location in the html document. any header() redirect needs an exit/die statement after it to stop program execution. don't use a loop to fetch a single row of data from a query. just directly execute the fetch statement one time. any dynamic value you output in a html context (email, web page) needs to have htmlentities() applied to it to help prevent cross site scripting.

the blank page is either due to $_POST["submit"] not being set (all the code is skipped over) or it's because you are not displaying the contents of the $error variable when it contains error(s).

the database extension is responsible for providing the interface between your application code and the database server. it is used to make the connection, execute queries, and fetch/test the result from queries. so, updating old code to use a new and different database extension would involve replacing the existing connection, query, fetch, and result-test statements with the equivalent statements from the new extension. the PDO extension brings two things to php that eliminates a lot of old implementation logic, 1) prepared queries, when supplying external, unknown, dynamic data values to the query when it gets executed, and 2) exceptions for errors. a prepared query is a one that has a simple ? place-holder in it for each data value, the query is then prepared, as a separate step, and is supplied the actual data values when the query gets executed. all the extra code/syntax you may have now that's trying to make each different type of data safe and get the values into the sql query statement are removed. for your posted code, that would eliminate the protect() calls and eliminate all the extra quotes and concatenation dots around each variable in the sql query. for the UPDATE query you have shown, it would look like this - // build the sql query in a php variable. this helps when debugging, you can echo the query, it separates the sql syntax from the php syntax as much as possible, reducing typo mistakes, and will lead to further simplification of the code (common/repetitive logic can be consolidated) $sql = "UPDATE eusers SET Online = ? WHERE id = ?"; // prepare the query - this sends the sql query statement to the database server, where it will be checked for syntax errors and the query execution will get planned // $pdo in the following is the name of the variable holding the instance of the PDO database connection $stmt = $pdo->prepare($sql); // execute the query, supplying the variables that were removed from the sql query statement as an array. $stmt->execute([ $time, $_SESSION['uid'] ]); // for an INSERT, UPDATE, or DELETE query, use the following to get/test the number of affected rows - $affected_rows = $stmt->rowCount(); for a non-prepared query, all types - SELECT, INSERT, UPDATE, DELETE, you would just use the query() method, instead of the prepare()/execute() calls. for a SELECT query, you would then use one of the available fetch methods to retrieve the data. // for a query that will match at most ONE row of data, use the following to fetch a single row - $var = $stmt->fetch(); // for a query that will match a set of zero or more rows of data, use the following to fetch all the rows at once - $var = $stmt->fetchAll(); // the rowCount() method isn't available for all database types that PDO can be used with. // the universal way of testing if or how many rows of data a query matched is to just fetch the data and test the fetched result (a true value means there is data) or use the php count() function to get the number of rows of fetched data. // for the above two fetch... examples, to just test if the query matched any data - if($var) { echo "the query matched some data. var contains the data from the query."; } // if you actually want a count of the number of rows a query matched $num_rows = count($var); echo "the query matched $num_rows rows."; next, exceptions for errors. you ALWAYS need error handling for any statement that can fail. for database statements, if you use exceptions for errors and in most cases let php catch and handle the exception, php will use its error related settings to control what happens with the actual error information (database statement errors will 'automatically' get displayed/logged the same as php errors.) the exception to this rule are for errors that are 'recoverable' by the visitor to your site. these would be things like inserting/updating duplicate or out of range values. in this case, your code would catch the exception, test if the error number is for something that your code is designed to handle, then setup a message for the visitor telling them what was wrong with the data that they submitted. if the error number is for anything else, just re-throw the exception and let php handle it. lastly, the following is typical PDO connection code that shows setting some common options - $DB_HOST = ''; // database host name or ip address $DB_USER = ''; // database username $DB_PASS = ''; // database password $DB_NAME = ''; // database name $DB_ENCODING = 'utf8'; // db character encoding. set to match your database table(s) character set $options = [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, // set the error mode to exceptions PDO::ATTR_EMULATE_PREPARES => false, // run real prepared queries PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC // set default fetch mode to assoc ]; $pdo = new pdo("mysql:host=$DB_HOST;dbname=$DB_NAME;charset=$DB_ENCODING",$DB_USER,$DB_PASS,$options); this should cover everything needed to address the database statements in the posted code. i'll let others comment on what your code is doing that it should do differently.

your code is apparently (there's too much code to sift though to really tell what it is doing in all cases) using the product_code as the cart's array index. this is the preferred method, since you can DIRECTLY test or reference the data in the cart via its index. to test if the item is already in the cart, all you need is an isset() test. to modify or delete existing data, just directly modify/unset it via the index. to insert a new item into the cart, just set/assign it using the new array index value. if the submitted product_code isn't valid (doesn't match any product/school choices) either due to a programming mistake, a product/choice being deleted after someone views the choices (choices shouldn't actually be deleted, just updated to indicate they are no longer available), or a nefarious data submission, you should setup an error message and report this condition to the visitor, i.e the selected product was not added to the cart, not a valid choice. you have a select/option menu for size choices that there's currently no processing code for. different sizes of something should be a unique and separate product_code. if you cannot change the design to do this, you will need to validate the submitted size choice, store it in the cart, display it when the cart is displayed, then finally store it when the cart is converted to an order. you will also need to qualify any cart add/remove operation with the submitted size selection. if there's 2 large size of some product_code and 1 small size of some product_code in the cart and someone adds one more small size of that product_code, the correct quantity needs to be modified. i would add a second array index to handle this and for anything that doesn't have a size choice, use some unique size value to indicate not to treat the entry as a size choice. lastly, don't put external, unknown, dynamic values directly into sql query statements. use a prepared query instead.

the key to this working is probably emulated prepared queries vs true prepared queries. when you make the database connection are you setting the pdo emulated prepared query attribute to a false value? are you really sure you want or care to do this? since this doesn't return the data types for a non-prepared query you will always need to use a prepared query, with the overhead of an extra round-trip communication with the database server, for every SELECT query, even if you are not supplying any data via a place-holder.

see this reply -

the OP's logic for fetching data from the SELECT query is all messed up, resulting the (unnecessary) while(){} loop logic being skipped over.

the form in the code at the top of this thread is not expecting a link to supply the value. it is expecting the value in - $_POST['id'] - and the reason for the posted form processing code to see an isset/non-empty value is because it is probably a php error message about an undefined index.

that would indicate that $_POST['id'] isset() and isn't empty(), and that the php code ran through the execute() call without any error. the most likely problem is that the id value being submitted to this page of code isn't a value that matches any data. what is the code that produces the 'delete' form that submits to the posted code? btw - is the 'confirmation' form in the posted code even being displayed? since the posted code operates on the initial submitted $_POST['id'] value from the 'delete' form, i doubt that any of the html in the posted code is even being output.

what DOES the page do when you submit the form? does the page just refresh and re-display the form, produce a blank page, or does it redirect to one of - teamsTabel.php/read.php/error.php?

here's an alternative method. build the links that you output on a page, starting with a copy of any existing get parameters, plus whatever get parameters the link contributes. an example - // get a copy of the existing $_GET parameters (leave $_GET unmodified so that any other functionality on the page has access to the original values) $get = #_GET; //create link(s), such as pagination links // set the element in $get that this portion of the software is responsible for $get['page'] = x; // build the query string part the the url $qs = http_build_query($get,'','&amp;'); // produce the link echo "<a href='?$qs'>x</a>"; by dong this, any code that produces a link only sets, modifies, or unsets the get parameters that it is responsible for, but the link carries all other existing $_GET parameters.

except that you didn't need to change the variable names and when you did, you mixed them up. within the scope of the function code, you have a SELECT sql query statement, you are preparing it, executing it, and fetching a row of data from it. why not use $query, $stmt, $result, and $row for variable names for this operation regardless of the meaning of the data that is being queried for and save the time and trouble, since there's a mistake now, it took you to push a bunch of keys on a keyboard?

do NOT put external, unknown, dynamic values directly into an sql query statement, since any sql special characters in the values will break the sql query syntax. use a (proper) prepared query, with a ? place-holder in the sql query statement for each value, then supply the values as an array to the execute([...]) call.

what exactly is the error you are getting and what is your database specific code that's using the submitted value?

according to your php script, you have changed the database root password to be 'deanna1999'. you will need to change phpmyadmin's configuration password setting to be the same.

in the XAMPP control panel, the MySQL Admin tab opens phpmyadmin.

most of the all-in-one development systems (XAMPP...) include phpmyadmin. which/how did you obtain - your development system?

you can examine the data in the database using a tool like phpmyadmin. next, you should have php's error_reporting set to E_ALL 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 that it detects. while you are making changes to the php.ini, set output_buffering to OFF, so that any messages from your code or non-fatal php error messages will be seen and not discarded at the header() redirects. you should also have error handling for all the statements that can fail. for database statements, just use exceptions for errors and in most cases let php catch and handle the exception, where it will use its error related settings to control what happens with the actual error information (database statement errors will 'automatically' get displayed/logged the same as php errors.) if you need, someone can post how to enable exceptions for errors for the mysqli database extension or if you switch to the much simpler PDO database extension.

if you index (pivot) the $result data using the job_number and the line_item as the array indexes when you retrieve it, you can DIRECTLY test/access the data. no searching is needed. what is the overall goal of doing this? if its to find if data already exists in a database, in order to decide if you should perform some operation on it, you can (probably, depending on what overall goal you are trying to accomplish) do this all in a query, by setting up a unique composite index consisting of the job_number and line_item.

i would create arrays with the choices in them, then just use in_array() to validate the submitted values. once you have an array of the choices, you can dynamically build the <option>...</option> markup, so that just by altering the defining arrays, you can change what the code does without writing out conditional logic or html markup for every possible choice.

you can only supply data values via prepared query place-holders. you cannot supply identifiers (column, table, database names) or sql syntax/keywords (comparison operators.) to safely do what you are trying, you must validate that the submitted column name and comparison operator are exactly and only permitted values, before building the sql query statement with them in it.