mac_gyver

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?

there are a number of issues in the code that are producing php errors. to get php to help you, find the php.ini that php is using and set error_reporting to E_ALL, display_errors to ON, and output_buffing to OFF. stop and start your web server to get any changes made to the php.ini to take effect. you need to ALWAYS validate inputs to your code before using them. if you are selecting from existing catalog (id) values, you should have some type of select menu and not require the user to remember and type in values. another recommendation is to separate the database specific code, that knows how to query for and fetch data, from the presentation code, that knows how to produce the output from that data. to do this, just fetch all the data into an appropriately named php variable, then test/loop over this variable in the html document. this will make testing easier, since you can 'see' if all the data you are getting is what you expect (it also makes asking for help easier since someone can make up some data to see what your code is actually doing, without needing any of your actual database information.) next, add the following line of code near the start of your php code so that you can see what data is actually being submitted - echo '<pre>'; print_r($_POST); echo '</pre>'; by putting the numerical index 1st, the array(s) of data being submitted are not what you think. lastly, the reason you are not getting the ITEM_NAME form fields is because the html markup is broken. don't concatenate things unless needed. you should also validate your resulting html markup at validator.w3.org

to get php to help you, find the php.ini that php is using and set error_reporting to E_ALL, display_errors to ON, and output_buffing to OFF. stop and start your web server to get any changes made to the php.ini to take effect. you should then be getting some php errors when you run your code that will help you find what the problem is.

a. the echoed time values should have been correct. are you sure about the posted code and the output that you got? b. browsers and web servers don't interact in real-time. even if you try to flush() the output, you are not very likely to get the result you want (see the php.net documentation for the flush() statement to see all the problems with trying to do it this way.) c. people don't like to wait on web pages to display things for x amount out time (it's either too long of a value or too short of one to suit the current visitor) or to redirect around on your site. the only redirect you have upon successful completion of post method form processing code should be to the exact same url of the current page to cause a get request for that page. if you want to display a one-time success message, store it in a session variable, then test/display/clear that session variable at the appropriate place in the html document. any navigation to other pages should be handled using navigation links where the visitor can choose where they want to go to next.

no. this results in a bad User eXperience (UX), takes more code, and gets your users used to automatically changing urls on your site, which increases the chance of a phishing site working. the form processing code should be on the same page as the form and the only redirect, upon successfully completing the form processing code, should be to the exact same url of the current page, to cause a get request for that page. any navigation to other pages should be via navigation links that the user can choose where he/she wants to go to. the form processing code would go above the start of the html document. you should also re-populate the form field values/selections when you re-display the form when there are validation errors. you didn't provide any details, but post method form processing code should - detect that a post method form was submitted before accessing any of the form data. if there is more than one form on a page, add logic to detect a unique value in the form data (a hidden field) to control which form processing code to execute. keep the submitted form data as an array, then use elements in the array throughout the rest of the code. trim all input data before validating it. you can do this with one array_map() statement, since you are keeping and operating on the data as a array. validate all the inputs, storing validation error messages in an array, using the field name or another appropriate name as the array index. this array is also an error flag. if the array is empty, there are no errors and you can use the submitted data. you can test/display the contents of this array at the appropriate point in the html document. if there are no validation errors, use the submitted data. if there are no (new) errors after using the submitted data, redirect to the exact same url of the page to cause a get request. if you want to display a one-time success message, store it in a session variable, then test/display/clear that variable at the appropriate point in the html document.

the username is a value that originally came from external submitted data. depending on your registration code's validation logic, it could contain anything, such as a hexadecimal encoded string, consisting of just letters and numbers (a hexadecimal encoded string, in a non-string context, will be decoded into whatever string it actually contains), or it could contain single-quotes, that if put directly into an sql query will allow sql injection. it sounds like you think that using a prepared query ONCE, when the data was first submitted and stored makes the value safe to use in all future queries. it does not. it only made that first query safe. any value that ever came from external, unknown, or dynamic data (recently, a year ago, or a year from now, when your application gets updated to get usernames via a call to an external api, where you don't know what type of characters it might contain) must treat the value as unsafe in whatever context the value is being used in (sql, html/css/javascript, email header, filename, system/shell, ...)

you need to define what output your code is going to produce (before you write the code.) if each of the three sections of data is to be a separate html table, you need an opening <table> tag at the start of each table and a closing </table> tag after you have output all the <tr> ... </tr> rows in the table. we cannot help you with any problem with code you tried unless you post that code. you have one opening <form ...> tag for each of the three sections of data, but you are outputting a closing </form> tag inside the data loop. after the 1st closing </form> tag, for the 1st row of data, the browser doesn't have any idea what the rest of the form fields and submit buttons are for. are you sure you even need/want forms for this part of the output? why are you even outputting the data values in readonly form fields?

the html markup has a number of mistakes - some missing <tr></tr> tags, no closing </table> tags, and opening/closing <form></form> tags in the wrong places. this last item is probably what's causing the wrong operation. you should validate the html of the resulting page at validator.w3.org for what you are apparently doing, a 'view more' link, just use a button as a html link, with a type id (paye/contract/permanent) and a record id as get parameters in the link. there's really no need for the post method forms (and the search form should use method = 'get'.)

if you are currently getting undefined index errors, it means $row exists, but doesn't contain what you think. what columns are in the uni2020 table? what does using var_dump($row); show? the above line of code is not doing anything, because of the ; on the end of it. a lot of these issues would not exist if you organized your code better. your code should be laid out in this general order - initialization - define, require, create, ... things your page needs, such as the session_start() statement, a database connection, configuration values, ... post method form processing code - a post method form should be used for things that create/update data on the server or perform an action such as sending an email. you should detect if a post method form has been submitted before using any of the form data. get method business logic - get/create data needed to display the dynamic content on the web page. you should fetch the data from any query into an appropriately named php variable, then test/reference that variable in the html document. html document/template - using simple php code or an actual template system, produce the actual html document, using the data produced from the above sections of code. the php error settings should be in the php.ini on your system, not in your code file. next, you need to validate all inputs to any section of code before using them, setting up and displaying a user error message for any 'required' input that doesn't contain an expected value. if $_GET['ID'] is required for the page to work, it is a user error if it doesn't exist. you should be setting up a message for the user telling them that no UniversityCourse has been selected. at the point of echoing the result from the SELECT query, if the query did not match any data, you should be outputting a message stating so, and only attempt to echo the values if they exist. inside the post method form processing code, if any of the inputs are 'required', but they are empty, that's a user error. you should be setting up a unique message for each empty input, telling the user which inputs they did not enter a value for.

there are three current problems - 1. you are getting a fatal runtime error, due to both where you put the php statements and that one of the statements is using a wrong variable name, but you don't have php's error related settings set up so that php will help you. when learning, developing, and debugging code/query(ies), you need to display all php errors. 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 insure that any changes made to the php.ini will take effect. 2. where you put those lines of code is nonsense. you put them before the point where you are executing the sql query. this says you are not even looking at what you are doing. you must be aware of what each line of code is doing and what it is contributing to the overall goal. the first line of code, which is attempting to fetch all the rows of data from the query, should replace the current line of code that's fetching just one row of data. it goes in your program at the point where you are fetching the data from the query, which would be after the point where you are executing the query. the second line of code is the start of the loop. it would go at the point in the html document where you are going to repeat the output for each user. you would 'close' the loop, with a } at the end of the block of html that you are repeating for each user. 3. the first line of code you copied, is using a wrong variable name. copying code is not programming. that's just you acting like a human Optical Character Reader (OCR) program. again, you must actually look at and read what the lines of code are doing. in your code, the $start variable (which is poorly named, use something like $stmt to indicate the variable holds a PDOStatement object), is what you would be calling the ->fetchAll() method on.

the sub-query was originally selecting everything, the g.*. you need to select the end column, so that there is a t.end for the outer query to test.

does any part of the output you got look like it would correspond to the next step of -