mac_gyver

you need to read @requinix's reply about the data type of the expires column. actually, you need to slow down, define what you want each part of the code to do, then test and observe the result you get at each step so that you are actually learning by doing. the php error message you most recently got was the same and for the same reason as at the start of this thread, a different number of prepared query place-holders vs the number of bound inputs in the php code. you also have a case later in the code that will produce the same error due to the use of an $email variable in an sql query vs correctly using a place-holder in a prepared query. next, you have have a serious functionality problem in that your code will allow empty password/password2 inputs to reset the user's password, due to not having exit; statements after every redirect. this is made worse by the form and the form processing code being on different pages, which requires the user to keep reentering these values every time there is a validation error. you should put the form and the form processing code on the same page, the only redirect you should have in your form processing code is to the exact same url as the current page upon successful completion of the form processing code, and you should always have an exit; statement after every redirect.

you can use the PDO classes (PDO, PDOStatement, and PDOException) at any time in any code.

if you are asking this because the mysqli prepared query programming interface is ridiculously overcomplicated and inconsistent, switch to the much simpler, more consistent, and better designed PDO extension. no. it only works for string data and then only if the character set that php is using is the same as your database table's. a prepared query works for all data types. also, aside from trimming data, mainly so that you can detect if all white-space characters were entered, don't alter user submitted data. just validate data and use it if it passes validation. by altering data, you are changing the meaning of it which can lead to security holes or unexpected operation in your application, having nothing to do with sql special characters in data values. yes. a true prepared query (PDO has an emulated prepared query that suffers from the same character set mismatch between php and your database table's) prevents any sql special characters in data from breaking the sql query syntax, by separating the parsing of the sql query syntax from the evaluation of the data values.

the simplest and most efficient way of doing this would be to query the database to get all the data matching the date range you are trying to display, fetch all the data into a php array variable, using the date value as the main array index. if there can be more than one piece of data per day, when you are fetching the data store it as an array of rows of data. then, as you are looping to produce the output for the calendar, for each day, form a date value in exactly the same format as was used for the array index values, test if an element isset() in the array of data, and if so, reference it when you are producing the output for that calendar's day.

if you do this - you will end up with code that looks like this - $out = ''; foreach($indexed_data as $type=>$arr) { // start a group $out .= "<optgroup label='$type'>"; foreach($arr as $row) { // add the output for each $row of data within the group $out .= "your makdup here for the <option ...>...</option> tag"; } // finish the group $out .= "</optgroup>"; }

that's an acceptable var_dump() output. the length matches the number of displayed characters. i suspect you are seeing the result of two (or more) requests to the page. for the first request, there is an input value and when you are using echo/var_dump to display it, this is preventing a header() redirect, that's causing additional request(s), which don't have the expected input. you are seeing the displayed result from the last request made. this 'works' when you hard-code the value, since all requests have the input value. so, two things - if it sounds like your code is capable of doing this, you will need to find and fix what's causing the additional request(s) and if you cannot determine what's causing the problem, you will need to post all of the code needed to reproduce the problem. you should always validate all inputs before using them (yes a session variable is an input to your code) and setup/display a message letting the visitor know that a 'required' input is not present. lastly, why is this value in a session variable at all. that's generally a sign that you are doing something in the hardest way possible.

the value probably contains some non-printing character(s). what does var_dump($_SESSION['bid']); show?

you got an sql syntax error message calling your attention to a specific point in a query. did you look at that sql query and attempt to determine what might be wrong with it at that point?

no. the parameters and values in code can come from any expression, such as a literal string, a variable, the return value from another function call, a math/logical operation, ... you would define a data structure (array or database table) that contains a list of the expected form field names (types, validation tests...) you would then loop over this defining structure to dynamically test/validate the inputs. the field name, which would be in a variable, would be used in place of any hard-coded associative field name in the code. except for unchecked check-boxes and radio-buttons, all other form field types will be set once the form has been submitted. after you have detected that a post method form has been submitted, you would only use isset() for check-boxes and radio-buttons. for all of the 'always set' field types, you should test if they are equal (or not) to an empty string.

as a side note - if you use the PDO::FETCH_COLUMN fetch mode with the fetchAll() method, you will directly get an array of the (column) values, rather than an array of rows of data.

for the $jokes variable to not exist, either the query failed due to an error or there are no (matching) rows in the database table. for the first case, most database statement errors are fatal problems, either due to programming mistakes or the database server not running, and there's no point in code on the page continuing to run at all. therefore, you would want your error handling to display the actual error information when you are learning, developing, and debugging query(ies) and to log the actual error information when on a live/public web server. to do this, simply let php catch 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.) you would then remove any existing database statement error handing, so that you don't need to keep track of if you are actually displaying/logging the output from it. the exception to this rule are execution errors for inserting/updating user submitted data and a duplicate or out of range error can occur. in this case, you would want your error handling to catch the exception, test if the error number is for something your code can handle, then setup and output a message telling the user what was wrong with the data that they submitted. for all other error numbers, just re-throw the exception and let php handle it, as described above. short-version: only use a try/catch block for database statement errors when a visitor on a site (not you as the programmer/developer) can do something about correcting the error. for the second case, your code producing the output should test if there is data to display, and either output a message stating there is not, or use the data to produce the output.

here's a page with a more specific date sort example - http://www.javascriptkit.com/javatutors/arraysort2.shtml

you will get a false return value if an error occurred (you will get a zero return value for no match.) you can specifically detect the false value and log both the $needle value and the debug_backtrace() information.

if you are trying to paginate an array of data, just use array_slice(). it takes the same offset and length values as the LIMIT clause in an sql query would. this would eliminate all this 'glue' logic. you would just foreach(){} loop over the array of data returned. this will also work correctly for a partial last slice or an initial slice with less than ROWS_PER_PAGE elements in it. if this data is coming from an sql query, why aren't you just getting the requested page of data directly in the query?

found this online -

the value returned from the ->execute() method is - you don't fetch data using that returned value. ->query() and ->prepare() are PDO methods. they both return a PDOStatement object (when successful.) ->fetch() and ->execute() are PDOStatement methods. ->fetch() returns a row of data (or a false if there's no data to fetch) and ->execute() returns a boolean value as listed above. typical code for a non-prepared query - $sql = "build the sql query statement in a php variable"; $stmt = $pdo->query($sql); // fetch a single row of data $row = $stmt->fetch(); // fetch all the rows of data $rows = $stmt->fetchAll(); typical code for a prepared query - $sql = "build the sql query statement in a php variable. ... WHERE founder LIKE ? ..."; $stmt = $pdo->prepare($sql); // provide the corresponding input(s) as an array to the execute call - $stmt->execute(["%$keyword%"]); // fetch a single row of data $row = $stmt->fetch(); // fetch all the rows of data $rows = $stmt->fetchAll(); the only lines that change are the ->query() v.s. ->prepare()/->execute() next, don't run a query multiple times just to get the column names. either use the PDOStatement ->getColumnMeta() method, or more universally, fetch all the data from the query into an appropriately named php variable (see the ->fetchAll() method), then reference the zeroth row [0] of that fetched data to access the column names. lastly, when you make the PDO connection, set the default fetch mode to assoc, so that you don't need to specify it in each fetch statement. when you make the connection, you should also set the error mode to exceptions and set emulated prepared queries to false.

you should allow for multiple stock in events per date. this will assign a 'stock in id' for each event that increases the stock. when you consume stock, you would insert 'child' records, using the parent's stock in id to relate the stock out event back to the corresponding stock in event. if you consume stock from more than one stock in event, you would insert a stock out/child record for each amount you take from each stock in event. to find the earliest stock in event(s) that has(have) an available stock amount equal or greater than a needed quantity, you would join the parent and child records ON the stock in ids, summing the plus stock in amounts and subtracting the stock out amounts. i'm sure @Barand will be along shortly to post an example of how to do this.

it will probably take having all the code that's part of 'it' to be able to help.

you probably have some broken html, prior to that input field, due to the short opening php tags <? being used. when you do a 'view source' of the page in any of the browsers, do you see the raw php code or do you get the values that php is trying to echo onto the web page?

if you index/pivot the data, using the type value as the main array index, when you retrieve the data into a php multi-dimensional array, it is clearer where the start and end of each section is when you then use two nested foreach(){} loops to produce the output.

you should have three tables. the asset table is where the items are defined, with id, name and any other columns needed to describe each asset. this will assign an asset id. you would then have an asset_user table to store the user(s) who have each asset, with id, asset_id, user_id, and any other columns needed to describe the asset/user data. you would then use a LEFT JOIN between the asset and the asset_user table, and a LEFT JOIN between that and the users table, to get the assets, plus any optional user information. If there is no user to join with, you will get NULL values for things you select from the asset_user and users tables. also, please list out the columns you are selecting in your query (this is even more important with multi-table queries) and don't put external, unknown, dynamic data values directly into a sql query statement, use a prepared query.

define: "doesn't work"? exactly what did you observe in front of you that leads you to believe that something about the code you have posted doesn't work? did you get a blank page, a bunch of php errors, a database related error, the output about - No Search Result Found, just some of the matching search results, all the database data was displayed, the displayed data was not in the expected order, did the page just refresh, did it appear like the clicking on the button did nothing at all, or a number of other possible symptoms? knowing what symptom you observed, narrows down the problem to just a few things that can be investigated further. next, you should be getting php errors from this ridiculously deficient code you found on the web and are taking a chance with by executing it on your server. this says you don't have php's error related settings setup so that php would help you while learning, developing, or debugging code/query(ies). find the php.ini that php is using and set error_reporting to E_ALL and set display_errors to ON. stop and start your web server to get any changes made to the php.ini to take effect.

doing a search on the www would be of some help. there are countless examples posted on the web showing all the different skills/parts you would need to build this application. designing code involves defining what the user will see and be able to do on each step of a process. this leads to defining what data, if any, you need as an input, what processing you are going to do based on the input data, and what result or output you are going to produce. when a user browses to your category search page, what will they see? a (get method) form with a text input (assuming you don't want just the category menu) and a category (select/option) menu. you can research on the web what the html for those are. next, you would want to dynamically create the option choices by querying the database table where the categories are defined. this will give you the category id (the option values) and the category name (the option labels) data. you would loop over this data to produce the option choices. you would also want to make the search form 'sticky' by populating the text field value with any existing input value and pre-selecting the option that matches any existing selected input value. for safety, you would want to apply htmlentities() to any dynamic data value when you output it onto a web page. this will get you a user interface for the first step in the process. once you get this working, you can move onto the next step of validating the search input(s) (see my reply in your other thread) and safely using them with a prepared select query to find and display any matching data.

in your previous thread - https://forums.phpfreaks.com/topic/311357-problem-with-mysql-data-to-html-table/ you had code that successfully fetched and displayed one row of data. based on the sql query you are showing now, you would want to use that same design pattern, not the design pattern that you were given that operates on multiple rows of data. based on your statements, edit: and the undefined index error you just posted, the get input probably doesn't contain what you think. your code should ALWAYS - validate all inputs before using them. if the get input isn't set or is empty (after being trimmed and cast as an integer), that's a user error and you should set up and display a message telling the user what was wrong with what they did or didn't do. list out the columns you are selecting so that anyone reading the query/code will know what you are trying to do without needing to know your database table definition. test if a select query matched any data before trying to use that data. if the query was successful (no errors), but didn't match any data, you should set up and display a message telling the user that there is no data to display, rather than trying to echo data that doesn't exist. don't use a loop to fetch the result from a query that you expect to match at most one row of data. just fetch that single row of data (refer back to your original code in the previous thread i linked to). your current loop, since $result contains a single fetched row of data, is looping over all the columns in that single row of data and is meaningless. don't copy variables to other variables. just use the original variable that data is in, like you were doing in the original code in the previous thread i linked to. short answer - 1.) you need to provide a good User eXperience (UX), by letting the user know if they did something wrong or that there is no (expected) data to display, and 2) code you had about a month ago did what you are trying to do now. learn from and build upon things you did before.

how do you know that, especially since you should be getting a status_id number as the returned value? perhaps there's some problem with the code that's using the result from calling that function? what is the (default) fetch mode you are using for the ->fetch() method call? have you set a default fetch mode yourself or are you using the default, default fetch mode? any chance you have more than one database and are selecting the wrong one?