mac_gyver

When the web page is messed up, what does the 'view source' in the browser show?

this is a character/string data type. comparisons between strings are character by character, and the character '8' is greater then the character '1'. numbers should be stored in an appropriate numerical (integer or decimal) data type.

programming is easiest when you define what Inputs you have, what Processing you are going to perform on those inputs, and what result or Output you are going to produce - IPO. after you have detected that a post method form was submitted, trimmed all the input data, mainly so that you can detect if all white-space characters were entered, validated that 'required' fields are not empty strings, if the password and confirmation password fields have no validation errors, you would compare the password value with the confirmation password value.

modern php (8+) uses exceptions for database errors by default, for the connection, query(), exec(), prepare(), and execute() calls. if you are not yet using php8+, you should be, but if not, you should set the error mode for the database extension you are using to use exceptions, since this simplifies and future-proofs the code. when using exceptions, no discrete error checking logic will ever get executed upon an error and should be removed. when using exceptions, if execution continues past a statement that can throw an exception, you know there was no error without needing to check the result from the statement. the $_mysql variable in your code is the prepared query statement object. if the prepare() call succeeded (didn't throw an exception), the remainder of your code doesn't need to test $_msyql to know that the prepare() call was successful. the $_mysql variable only indicates that the prepare() call was successful. it doesn't indicate if the row of data was inserted. the username and email (which you are not using in the query) columns must be unique. these need to be defined as unique indexes in the database table. to detect if duplicate data was attempted to be inserted into these columns, you would have try/catch exception handling for the execution of this query, where you would test for a duplicate index error number (1062). since there is more than one unique column, you would execute a SELECT query at this point to find which columns contain duplicate values, and setup a message for the user for each duplicate value. after the execution of this query and the duplicate index error exception handling, if there are no user/validation errors, you know that the row was inserted into the database table. as to the rest of the code and the implementation of the above - the code for any page should be laid out in this general order - 1) initialization, 2) post method form processing, 3) get method business logic - get/produce data needed to display the page, 4) html document. use 'require' for things your code must have. as has already been posted, the post method form processing code needs to detect if a post method form was submitted before referencing any of the form data. note: there are cases where a submit button won't be set (there may not be any $_POST data) and you should not test if it is to determine if you should run the post method form processing code. if you need to distinguish between multiple possible form processing code on a page, use a hidden form field, such as name='action', with a unique value that indicates which form processing code to run. keep the form data as a set in a php array variable, then operate on elements in this array variable throughout the rest of the code. i.e. don't write out line after line of code copying variables to other variables. except for unchecked checkbox/radio fields, all other field types will be set once the form has been submitted. you need to trim all user input data, mainly so that you can detect if all white-space characters were entered, before validating the data. you need to validate all inputs before using them, 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 (the array holding the user/validation errors will be empty), use the submitted form data. after using the form data, if there are no errors (an insert query can produce a duplicate index error for columns that must be unique, such as a username or email address), perform a redirect 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. if you want to display a one time success message, store either the message text or a flag value in a session variable, then test for this session variable, display the success message, and clear the session variable at the appropriate location in the html document. if there are errors, the code will continue on to display the html document, where you will test for and display any user/validation errors, either all at once or adjacent to the field they correspond to, and redisplay the form, populating the field values with the submitted form data, so that the user only needs correct the errors and can resubmit the form. to prevent errors when populating the field values the first time the form is displayed, when there is no existing form data, use php's null coalescing operator ?? to supply an empty string as the value. any dynamic value that you output in a html context needs to have htmlentities() applied to it, right before or as it is being output, to help prevent cross site scripting. you need to validate the resulting web page at validator.w3.org you need to use <label></label> tags for the form field label text. if you place the closing </label> tag after the field it corresponds to, you can eliminate any for='...' attributes and the corresponding id='...' attributes.

didn't the previous thread show a simple way of doing this? all you would need to do is go from the example code, that loops over and echos the form data, to code that builds and prepares the query, then executes the query inside the loop with each set of form data - // build and prepare the sql query statement $sql = "UPDATE cd006ccals SET ccalcourt=? WHERE ccalid=?"; $stmt = $pdo->prepare($sql); // example code looping over the form data foreach(array_keys($_POST['court']) as $index) { // execute the prepared query with each set of form data $stmt->execute([ $_POST['court'][$index], $index ]); }

you don't want to give hackers useful feedback as to if they were able to cause any specific problem on a site. you also don't want to give legitimate visitors information that they don't need to know and cannot do anything about. database errors are fatal for a page that is database dependent. all you need to let the visitor/hacker know is that the current page isn't working, and you need to log the actual errors. you never want to output the raw errors on a live/public site. modern php (8+) uses exceptions for database errors by default. when using exceptions, no discrete error handling logic in your code will ever get executed upon an error and should be removed, because execution transfers to the nearest correct type of exception try/catch block in your code, or to php if there is no correct type of exception handling in your code. this is the reason why you are not 'seeing' anything when you deliberately trigger a connection error. execution is going to php's uncaught exception handling, where php is using its error related settings (error_reporting, display_errors, and log_errors) to control what happens with the raw error information. php's error_reporting should always be set to E_ALL. on a live/public site, php's display_errors should be set to OFF and log_errors should be set to ON. this will cause all php errors, which includes uncaught exceptions, to be logged. if your server is setup this way, php should generate a http 500 error response. you can setup a custom http 500 page with any information or text on it that you want, such as - this page is not working, the site owner has been notified. please come back later to try again... if you need to handle uncaught exceptions more specifically, such as sending an email or sms when they occur, you can register your own uncaught exception handler - see https://www.php.net/manual/en/function.set-exception-handler.php as to your application code. you should only catch and handle database exceptions for user recoverable errors, such as when inserting/updating duplicate or out of range user submitted data. for all other query errors and all other type of queries, you should do nothing in your application code and let php, or if you have defined your own uncaught exception handler, catch and handle exceptions.

have you examined what the form data is - echo '<pre>'; print_r($_POST); echo '</pre>'; the first field is court. this code would be something like - // example code looping over the form data foreach(array_keys($_POST['court']) as $index) { // for demonstration purposes, echo the values echo 'Court: '.$_POST['court'][$index].'<br>'; echo 'Judge: '.$_POST['judge'][$index].'<br>'; // ... } here's an additional list of points for the code - you can select the database in the connection statement. if the only thing in an overall double-quoted string is a php variable, don't put quotes around the variable at all. if you put the database connection code in its own file, you can just require it when needed and you won't need to redact the connection credentials when posting the code that uses the connection. if the update query can result in duplicate data for any column(s) that must be unique (you would define those columns as a unique index), you would have try/catch exception handling logic in your code, test in the catch branch is a duplicate index error (number) occurred, and setup a message for the user letting them know that duplicate data was submitted. don't echo blocks of static or mostly static html markup. simply drop out of php and put the markup in-line. if you use php's short open print tag <?= and leave out the closing ; right before a closing ?> tag, you can echo php variables in markup using <?=$var?> syntax. you should list out the columns you are SELECTing in a query. a SELECT query that can match more than one row of data needs to have an ORDER BY ... term so that the rows of data are in a specific order. if a query doesn't match any data, output a message stating so, instead of outputting nothing. you can directly loop/iterate over the result object from a query. for what you are doing, you don't need to first fetch the data into $datas. you should always quote html attribute values. you need to validate the resulting web pages at validator.w3.org

the simple way of doing this is to use an array for the data, by using an array name for the form fields, with the array index being the row's unique id, e.g. name='court[{$data['ccalid']}]'. when the form is submitted, you can get the array indexes from the first field (see php's array_keys()), then loop over this array of indexes to access each set of data from the fields. also, you should not put dynamic values directly into sql query statements, where any sql special character can break the sql query syntax. use a prepared query instead, prepared once, before the start of any looping, then simply supply each new set of data when you execute the query. if is seems like using the mysqli extension with prepared queries is overly complicated and inconsistent, it is. this would be a good time to switch to the much simpler and better designed PDO extension. here's a list of general points for the posted code - modern php (8+) uses exceptions for database error handling by default. when using exceptions, no discrete error checking logic will be executed upon an error and should be removed. when using exceptions, your code will only 'see' error free execution. if execution continues past a statement that can throw an exception, you know there was no error without needing any logic to test the result of the statement. if this is the only form that can submit to this page, you don't need to test if the submit button is set. in fact, there are cases where the submit button won't be set and you should not attempt to test if it is. use 'require' for things you code must have. include/require are not functions. the () around the path/filename do nothing and should be removed. to get a form to submit to the exact same url of the current page, leave out the entire action attribute in the form tag. everything in the ...ccal table is for the ccal data. there's no good reason to include 'ccal' in every column name. this is just a bunch of extra typing you have to keep track of. you need to apply htmlentities to all dynamic values being output in a html context to prevent any html entity in a value from breaking the html syntax. textarea's don't have value attributes.

the OP was already told how to use var_export - https://forums.phpfreaks.com/topic/330113-ongoing-problem-with-missing-session-variables/#findComment-1657999 then given a copy/paste use - https://forums.phpfreaks.com/topic/330113-ongoing-problem-with-missing-session-variables/#comment-1659430 edit: and this problem isn't going to go away until the only session variable that is an input to this 'statement' code is the logged in user's id, so that the only code that affects what the processing is and what is displayed on this page, is the code on this page, and not in any processing on other pages.

firstly, this question is a php question. not a mysql question. the syntax of your if() {} conditional statement is broken. the ) is missing. there's no guarantee that the incorrect value is a NULL. i showed you in a previous thread how you can use var_export() to cause the actual value to be used in the storedata(...) call.

it is likely that the sql query is listing the column, but isn't providing a value. you should leave any autoincrement column out of the sql query statement. what is the php code and sql query in question?

YES, you can. var_export() - "Outputs or returns a parsable string representation of a variable" (from the documentation.) what it returns could be assign to a variable, just like you had typed it on the right-hand side of the = in an assignment statement in your programming editor. the first code you have shown in this thread, the error, and value you are logging indicate that the session variable is set, but that it doesn't contain one of the expected values. adding code testing if it is not set won't solve anything. you must find what the incorrect value is, then find and fix the code that's causing that value to be put into the session variable. that this session variable is even named 'countervalue' indicates it is being used somewhere for a different purpose. no wonder it is being randomly changed. OR you can fix the code as i have suggested. if any user can only have a single view, then query the database on each page request to get this value for the logged in user. if a user can select the view from a set of choices, this needs to be handled via a navigation menu and a $_GET parameter on the end of the URL, and validated on each page request to make sure that the value is permitted for the current user.

as a separate post, here is what you actually need to do. you need to start over, update all the code to current standards, organize the code, and have the code for any single operation, such as displaying the statement, on one page. i previously posted this (in fact i'm repeating everything multiple times with you), the code for any page should be laid out in this general order - initialization post method form processing - get/produce data needed to display the page get method business logic - get/produce data needed to display the page html document the only user related session variable should be $_SESSION['user_id'] (autoincrement primary index), to identify who the logged in user is. you should query on each page request to get any other user data, such as the username, role, permissions, ... all user entered input data needs to be trimmed before validating it. all input data to page - $_GET, $_POST, $_FILES, $_COOKEIE, $_SESSION, and some $_SERVER, needs to be validated before using it. if 'required' data is not valid, that's an error, and you would setup and display an error message instead of running code that's dependent on the input data. if input data is optional, and it is not set, you would setup a default value, such as a default view value if there is no view input. your page navigation and the view choice need to be handled using $_GET inputs. here a list of points for the last statement.php and SecureFunctionsBankPDO.php code you posted in this thread - your code should be organized so that you are not repeating yourself. require (and include) is not a function. the () around the path/filename do nothing and should be removed. the list of transaction type/category defined constants should instead be handled via a database table. the global keyword only has meaning inside a function, and even there it should be avoided as it produces code that's hard to debug. every query that has a dynamic value being supplied as an input needs to be a prepared query. due to cross site scripting, even values that come from trusted, logged in users, can be set to anything and cannot be trusted. the discrete logic in MonthlyTakings() will never match $row['Output'], since you are not SELECTing anything named Output. ColourPicker() should NOT directly reference a superglobal variable to get the view. there should be a call-time input parameter for the view. functions should not echo output. they should return the result they produce to the calling code so that the result can be used in any context. don't select all the columns and rows of data from a table just to get a count of number of rows. you should use SELECT COUNT(*) ..., then fetch the count value. don't get a count of the number of rows in a table and use this value as input to another query. this is not concurrent safe. you should not UPDATE a column to keep track of the balance. this can get out of sync with the actual data. you should query the actual data anytime you need to get the balance. the doctype is out of date and needs to be updated. you need to validate the resulting web page at validator.w3.org you need to be consistent. you are using require some places and include elsewhere. you should always use require for things your code must have. as has already been written, you need to use $_GET inputs for navigation, not a post method form. actually, the whole form around the statement content is pointless. you need to use css instead of in-line styling. every dynamic value output in a html context needs to have htmlentities() applied to it right before or as it is being output.

we are not sitting next to you. we don't have all the relevant code. if you won't do the things that have been suggested, we cannot help you. why are not posting the requested code? YOU CAN USE var_export() the way I suggested. this is the current storedata() call - StoreData($StartDate ."-" . $View); // *** Store data to trap this error *** change it to this - StoreData($StartDate ."-" . var_export($View,true)); // *** Store data to trap this error *** throwing random code at the problem won't solve anything. you must find what's causing a problem before you can fix it. you must find what the incorrect value is, then find where and how it is being set to that value. by using all these session variables to make your site 'work', you have created code where values used on one page can get changed by the code on a different page. the solution is to get rid of all the session variables, except for a user id, that identifies who the logged in user is. this 'CounterValue'/view should be a $_GET parameter on the end of the URL, since is determines what will be displayed on a page.

you still haven't done this - so, you don't know what the non-printing value actually is. it is likely an empty string '', not a null value. the null in the "Call to a member function fetch() on null" error is because GetAllData() returns nothing (null) when $View doesn't match one of he 4 values. you haven't posted ../secure/SecurePDO.php or SideMenu.php. where is session_init() defined? it's likely setting $_SESSION['CounterValue'] to the offending value. since this code could be redirecting to index.php and back to statement.php, whet is the full code being used on index.php (which i already asked you to post)? do any of these filenames being required/included exist at different paths within your project, so that different parts of your code could be requiring/including a wrong version of a file? i ask this because in the related code you have posted for this problem, there have been different versions of session_init() and variables being used that haven't been assigned a value in any of the posted code.