mac_gyver

no. the injected sql is normally used with SELECT queries to read other tables in your database. because you are already selecting data to display, all the injected sql needs to do is satisfy the syntax of your existing query, then it can add a UNION SELECT anything it wants, to get your code to query for and output things like the content of a user table including email addresses and hashed passwords. there's nothing syntactically wrong with the posted code, provided you are using php5.4+. you are likely getting a fatal run-time error, such as an uncaught pdo exception. do you have php's error_reporting set to E_ALL and display_error set to ON so that any run-time errors will be reported and displayed? if you are using a version of php that's lower than 5.4, you would be getting a php syntax error due to some php5.4+ specific syntax in use. what is your php version? the wild-card % are around the data, not part of the array index name. you would use the following, including the double-quotes - "%{$_POST['search']}%"

stopping sql injection is just one part of making a secure application. your query can be safe from sql injection, but your application can still be open to misuse. should all the users on your site be able to submit data to this code and update any record having any id value? if not, you would need a user permission system to control who can perform any action (an update query for events, in this case) or view any content (the 'edit/update' button part of an events list and the events update form for a particular record) and if they are restricted to only affecting records they are the 'owner'/creator of, or do they have permission to update any event record. to allow a user to pick which record to update, you would end up passing the id as a hidden form field value, which is what you are doing now. you would need to determine if the user has permission to run the update code at all and if he has permission to affect the record with the id value that was submitted.

in the first post in this thread, you had the correct syntax for an UPDATE query, just the desc column needed special handling since it is a reserved keyword. why have you now completely changed the syntax? the following is the syntax definition for an UPDATE query (from the mysql documentation) - the red parts are what is commonly used.

you will also need to put the % wild-card search characters around the actual data value in $_POST['search'] when you supply it for the query's execution.

array indexes/keys must be unique. it's not skipping. when you define three elements with the same index/key, each new definition replaces the previous one. depending on what you are trying to accomplish, you can make each array element have a region and city - $areas = array( 'region'=>"London", 'city' => "North", 'region'=>"London", 'city' => "South", 'region'=>"London", 'city' => "West", 'region'=>"Newcastle", 'city' => "North" ); or you could make a sub-array under each region - $areas = array( "London" => array("North","South","West"), "Newcastle" => array("North") );

if you read the documentation for that error number, you will find what setting affects it. this will also let you decided if you even want this check to be used, since it was just php doing it's own thing that's not in any way secure from tampering and therefore is pretty meaningless to use. if you don't want to use this particular php feature, just remove the line from the form markup.

you are actually using several of the statements with the wrong or non-existent variables. if you had php's error_reporting set to E_ALL and display_errors set to ON (the best place to set these is in the php.ini on your development system), you would be getting several php error messages due to the incorrect usage. if $con is your database connection, you would use that in the mysqli_prepare() and the $con->error. you would not use it in the mysqli_stmt_bind_param(). the mysqli_stmt_bind_param() uses the $stmt. next, you should have error handling for all the database statements that can fail (connection. prepare, execute), so that you don't run following dependent statements when an earlier one has failed. this would catch the case where the connection didn't work. you would never get to the point of trying to run code that depends on the connection. the easiest way of universally adding error handling for all the database statements, is to use exceptions. by using exceptions, your main code only has to deal with error free database statements. you don't have to write conditional logic in your code at each statement that can fail. lastly, are you open to using the PDO extension, rather than the mysqli extension? when using prepared queries, the PDO extension results in the cleanest code.

untested, but should work - // the code given in your last thread - $data = array(); foreach($items as $arr){ $data[$arr['start']][] = $arr; // index/pivot the data using the start datetime as the key } // the suggested processing in this thread - foreach($data as $time=>$arr){ echo "$time<br>"; // output a heading $arr = array_slice($arr, 0, 5); // get a maximum of 5 elements from the array foreach($arr as $element){ echo "Title: {$element['title']}, Description: {$element['desc']}<br>"; // output the data the way you want } }

that may be what you have as a setting, but what is the actual value that's in effect when the php code runs? what does the output from a phpinfo() statement show? also, where are you setting the error_reporting setting at, and does the phpinfo() output show that location to be the one that php is using on both systems? it's more likely that one system isn't using that setting at all or you have a local php.ini or .htaccess file that's overriding the setting or a syntax error in the php.ini file that prevents all settings after the error from having any effect. for the exact same code, this would normally be due to using short opening php tags. for the exact same code, this would normally be due to using short opening php tags in the included/required file.

from your last thread, you have the $data array. foreach($data as $time=>$arr) { // $time is the main array index time value // $arr is an array of the arrays of data under that time - do whatever you want with it here. }

so, what you are trying to do is output a maximum of 5 sets of data for each time value? if so, i would just loop over the result you got from your last thread on the forum, which would give the time and an array of the data for that time, and output the data the way you want it. you can use array_slice() to get a maximum of 5 elements from the array under each time value, then just implode or loop over that array, depending on how complex the formatting is, and echo the result.

yes, the } you have on line 114 does close the function definition. the error is due to the Heredoc closing tags (two places) being indented. they must be the only thing on a line and cannot have any characters before them on the line and can only have a ; and a newline after them on the line. the color highlighting in your programming editor should have stopped changing at the first EOF; to alert you to this problem (all the code after that point is considered to be part of the string.)

this is a sign that the host-name/sub-domain part of the url (the www. vs no www.) is inconstant and is changing due to the redirects and your session cookie setting for the domain isn't set to match all variations of your domain name. the php.net documentation tells you how to set it so that it does, but your code should also be consistent in the variation of your domain name that is being used. you also need a exit; statement after the header() redirect to prevent your code on the protected page from running while the browser is requesting the target url in the redirect. this could also be the cause of unusual session operation, if the rest of your code on the page is clearing or modifying the session variables. lacking a real permission system, you need to use in_array() to test if a value is or is not one of several possible choices. your code would end up looking like - // define the user types that are admins - $admin_types = array("Admin","Owner","Moderator"); // test if the current user is not an admin type if(!in_array($_SESSION['SalesCRMA'],$admin_types) { header('Location: http://www.mysite.com/logout.php'); exit; }

in addition to posting your code, you have to provide information about what works and what doesn't, what error or symptom you are getting that leads you to believe that your code doesn't work, and what result you did get. your post does contain information about what result you expected, through it's not entirely clear, without your code, exactly at what point you expect that result. if what you are describing is storing data into a database table, you would NOT combine the information into one field/column. you would have separate columns for the different information and only combine them when you display the information.

your database design needs help. you should not create x empty rows, then try to manage the data in those rows. you should only insert data that exists and delete data that gets removed. you can limit the maximum number of rows that can be inserted by using an INSERT ... SELECT query, with a COUNT() term and comparison in the SELECT part to only insert a row if the count is less than the maximum. to do this, you need to have a unique composite index set up for the player_id/card_id columns so that you cannot insert the same card_id for any player more than one time. see the following query - INSERT INTO player_deck (player_id, card_id, card_amount) SELECT -- the following values being SELECTed are the data to insert, unknown if you can use place-holders and bound data 1234, 4, 1 FROM DUAL -- dual is an allowed dummy table name to satisfy the FROM ... WHERE syntax WHERE (SELECT COUNT(*) FROM player_deck WHERE player_id = 1234) < 5 -- insert the data if the WHERE (subquery count) < 5 is TRUE the 1234, 4, 1 example data are the player_id, card_id, and card_amount values. you would supply these to the query. the player_id value occurs a second time later in the query. the 5 in the < 5 is the limit. you would change it to 60. if the count is less than this value, the row will be inserted. if the count is equal to greater than this value, the row will not be inserted. if you are actually trying to insert this data if it doesn't exist or update the card_amount if a row already exists, you can add an ON DUPLICATE KEY UPDATE ... to the end of this query (just tested.)

was just going to post the same. none of the UPDATE queries being shown make sense. you need to define what you are going to do for all the different possibilities and to get help from us, you need to provide that definition so that we understand all the different possibilities. for the input data, what will it look like when adding card(s) that don't exist? what will it look like when modifying existing card amounts? what will it look like when you remove card(s)? is the card_amount always 1? is the card_amount a value of a card, that is fixed or variable for any card id or is it the number of cards with that id, assuming you can have more than one of any card id? are there always 60 ids and 60 amounts in the submitted data? what do the -1 you have shown in the sample data mean? then, for each of the possibilities of adding cards, removing cards, or changing the card_amount, you would design the correctly type of query to insert, update, or delete the data.

in programming, the best way of dong something requires knowing the context. what are you actually doing, what problem are you having by doing it this way, and how many times in a program are you going to be doing it (if you have a set of data, you would use an array, and the coding would use a different method, than for one discrete variable)? the best answer for your situation may be to always define the variable with a default value first. the best answer for your situation may be to use something like a ternary operator to define and give the variable a value if a set of conditions are true or a default value if the conditions are not true. the best answer for your situation may be to skip over all the code that's dependent on a variable if the conditions are not met.

array keys/indexes must be unique, so your anticipated result is not possible. not knowing why are you doing this, what you are ultimately using the data for, which would produce the best result, i would recommend making an array with the start value as the main array key and the (start)/title/description data as sub-arrays under any start value. it would look like - $data['201601221400'][0] = array('start' => '201601221400', 'title' => 'FABLife', 'desc' => 'Mark Cuban (``Shark Tank\'\'); top five must-haves; collectors try to guess the prices of celebrity memorabilia; creating a high-end playroom and eliminating toy clutter without breaking the bank.' ); $data['201601221400'][1] = array('start' => '201601221400', 'title' => 'The First 48', 'desc' => 'A young man is robbed and killed while meeting up with a girl he met earlier; a man is gunned down outside an annual football game.' ); $data['201601221400'][2] = array('start' => '201601221400', 'title' => 'Teen Titans Go!', 'desc' => 'Robin makes the other Titans sell their treasured mementos from past adventures.' ); you would produce this by looping through the data, using the 'start' value as the main array key and appending an array consisting of the start, title and desc - $data = array(); foreach($items as $arr){ $data[$arr['start']][] = $arr; } echo '<pre>'; print_r($data);

no, you wouldn't have columns like that. i reviewed your last database related thread and a member mentioned Normalization. this is the same thing. short answer - there's one row in a table for each item of data and all the same meaning data is in the same table. by storing the data correctly, you can write simple queries that find any data that you want. storing the data correctly will also eliminate all the code you have to move data between tables. something tells me that the data you are showing us in this thread is actually derived/accumulated data. you should be calculating this when needed, not storing it in a table.

JOIN's are used when there is a relationship between different meaning data in tables. an example would be a clan table, that defines the clan name and assigns an id to each clan and a table holding the data you currently have. if you want to retrieve the clan name for display or search for data using the clan name, you would join the two tables using the clan_id columns. for what you are doing, you should have ONE table holding all the results. the date column you have will let you retrieve the data you want. If you want to retrieve the n most recent weeks worth of data, you would add a term in the WHERE clause to match rows having a date value greater then or equal to the starting date you are interested in.

you need to add the login form/form processing at any point that you expect a user to be logged in and she/he isn't. if you are at the point of needing a user permission system, you should probably be at the point of having a web site that handles all the processing/content through one main file, not though having a separate file for each different thing your site does. when a user logs in, you are authenticating who they are. this only involves matching the username and the hashed password in the user table and storing the user id in a session variable. to determine what a user may do or see on any page request, you would take the user id from your log in system and retrieve their current permissions. the reason to do this on each page request is so that any changes made to the permissions will take effect immediately. the code on your page would test if the current user has permission to perform any action or view any content that you have defined in your permission table.

you would use a html array name for the rec form field, where the array key is the SKU number - name='rec[1769057]' this will result in an array in $_POST['rec'] that you can use php's array functions on, such as a foreach(){} loop to loop over.the elements when providing data to your sql query.

rather than expect someone to do your work for you, how about sitting down and trying yourself. have you defined the work-flow that a site visitor will go through from arriving at the site, as an unknown 'guest' user, through completing payment for an order, and beyond when the ordered items are shipped, received, and possibly returned? This will define what data each page on the site will need to process and store as input data or retrieve for use to display the page. This will define the types of information you will need to have database tables for. then, before you write any code or create any database tables, take the design you have theorized, and 'walk' through the process for a made up user and some made up items to see if your design does what you want. modify your design as needed and repeat until you are confident you have covered 99% of the possibilities. then, write and test the code and queries that implement your design, making any needed changes along the way.

i'm wondering why the code in this thread, using mysqli, threw a way the code you posted in your last thread on this forum, using pdo, that apparent had a working date search - http://forums.phpfreaks.com/topic/300742-paginate-search-results/ especially since you have now posted that previous code, less the pagination logic, on at least one other help forum, expecting someone to spoon-feed you with the information you need to paginate the results. programming requires that you learn the meaning of what you are doing so that you can write code that brings together different concepts. all you are doing is trying to smash together pieces that don't even work together. by throwing away code and starting over, sometimes in a single thread, you are also throwing away the help you have gotten, because people are not going to keep reading randomly changing code from you to try and figure out what you are currently doing. if you want help, stick with one set of code and FIX the problems in it (using PDO is your best choice, since you need to use a prepared query to get the external data securely into the query). don't keep starting over. it will take you forever to accomplish anything.

your code is all over the place. in addition to mixing mysqli and PDO statements, you are making (apparently) two different PDO database connections AND the WHERE ... clause in your data retrieval query must be used in the total row count query so that the two queries match the same set of rows. you should form the the WHERE ... clause in a php variable, then use that variable in both queries. you should also get the total row count first, so that you can use it to limit the maximum page number so that a programming error or someone feeding your code invalid/large page numbers doesn't waste resources running the data retrieval query that will never match any data. edit: you also have a problem with the pagination links and the date filtering, you need to propagate any selected date filtering in the pagination links so that the the code will properly select data on each page.