mac_gyver

with a mysqli prepared query, $stmt ->fetch() does NOT return the row, it causes the bound result variables to be populated with the data that is fetched. a) it is much easier to use prepared queries with PDO, not mysqli. b) if your php version is high enough, use the ->get_result() method to convert the result from the mysqli prepared query into a normal mysqli result resource, that you can use a normal ->fetch_assoc() method on. this will also allow you to use the ->fetch_all() method to fetch all the rows into an array.

that would indicate you have html markup in the file, not just the php code you are showing us. perhaps you should show or attach the complete .php file and exactly what the 'view source' of the output is.

if you put an echo 'start'; statement in your file before your $mysqli = new mysqli ... line code and echo 'end'; after your echo $mysqli->host_info . "\n"; line of code, do you get either or both of the start/end being output to the browser?

if the php.ini that you are changing is the one that php is using, and you have confirmed that the settings took effect in the phpinfo() output, any php errors should be displayed in the browser when the .php page is output. in some cases, the php error messages are inside of html tags/form elements and are only visible in the 'view source' of the page in your browser.

there are no semi-colons ; and you will likely need to restart the web server to get any changes to take effect. the phpinfo() output should reflect the changes being made to the two settings.

do you have php's error_reporting set to E_ALL and display_errors set to ON in the php.ini on your development system so that php would help you by reporting and displaying all the errors that it detects? you will save a ton of time.

your first query/code should be throwing an error. there is no bound parameter in the sql statement (you cannot bind a table name anyway, you can only bind data values), so the bindparam() doesn't have anything to bind to and the execute() statement should be throwing an error about the number of bound parameters not matching or a similarly worded error.... have you set the PDO error mode to exceptions (it must be done after you make the database connection) so that you would be getting PDO errors (which are different from php errors) from the database statements? since the first query doesn't have any data values being put into it, you can just use the PDO ->query() method to execute that query. for the second query, the two values being put into the sql statement are produced by your code. the $start value is a calculated/assigned integer number, due to the fact that you are multiplying it by the hard-coded integer in $limit and the $limit is a hard-coded value from an assignment statement. if you were getting either of these values from external data (some people do 'rowination', where they are supplying the $start value directly in the 'pagination' links, rather than a logical page number and you can supply a dynamic $limit/rows per page value via a link), you would need to protect against sql injection in the values. so, for how you are producing the two values being put into the sql statement, you can also use the PDO ->query() method for this query.

some code you have, that's either part of the original uploading or downloading of the file, probably contains a new-line character in it, outside of any <?php ?> tags, and this character is getting prepended to the file data.

perhaps you missed this note below the age field in your profile -

you cannot use a setcooke() (or anything else that sends a http header to the browser) after you have sent any characters to the browser. your first echo statement is preventing the second setcooke() statement from working. if you had php's error_reporting set to E_ALL and display_errors set to ON, php would be telling you this. next, the $_COOKIE data comes from the browser. it is only available after the browser requests the page and sends the cookie data to the server. $_COOKIE data is not available on the same page request where it was set using a setcookie() statement.

which you were dong in both sets of code in your previous thread. not trying to give you a hard time (yet), but you must actually learn what each statement you are using does, so that you will know how it contributes to the goal you are trying to achieve, and where it belongs in your code to do it's job. then, when the goal isn't being met, you will have a good idea where to start looking to find what's causing the problem. these are the three different statements you were using in your previous code - $stmt = $db ->prepare (); // prepare an sql statement, that has place-holders in it for inputs $stmt ->bindValue(); // bind actual values to the place-holders in the sql statement $stmt ->execute (); // execute the query so, the flow is prepare, bind inputs, run the query. prepare, bind, execute. prepare, bind, execute... (okay, so now i am giving you a hard time, because you apparently didn't look at your code and try to figure out why it isn't working or what's different about it from the code you wrote before.)

no. the only one who knows what the context is for any line of code and goal you are trying to achieve is the person writing the code. it's up to the programmer to know what the statements being used do, so that they know how they will contribute to the goal being worked on, and to know if they belong in the code at all and where they belong at. putting the correct statements together in a meaningful way to accomplish a goal is the creative part of programming.

there's a comment about that in the first of my posts -

in the time the OP will need to spend to finish adding code to repopulate fields/check-boxes/radio-buttons with existing values, to display errors for each field, and to fix all the other problems in the code, times the number of form fields, and to also fix all the errors caused by typo's in the discrete/hard-coded field/variable names, he can learn enough php so that he would understand what a ternary operator is or to make use of the suggested method. for the OP, here's a basic example that shows the method i suggested for an input type='text' field. all the type= text, password, hidden, and submit fields you currently have would be handled by this method (with the addition of a switch/case statement.) adding code to handle checkbox/radiobuttons is not difficult, with a little php and html knowledge. see the comments in the code in any case. <?php // using arrays, you would define the form fields and just loop over the array to output all the form fields, rather than to write them out by hand // this example shows only one field // notes: // the array key is the form field name. // for the form field type, you would actually have a switch/case statement for the different types to output the correct html for each different type. // the 'value' entry is 'y' to determine if you output any existing value for a field. for a password field, you would typically not output any previously entered value. $fields['userName'] = array('legend'=>'Username','required'=>'y','type'=>'text','value'=>'y'); // you would add the rest of the field definitions here... you can produce the submit buttons too, by defining them in this array // form processing code, first check if a form was submitted - if($_SERVER['REQUEST_METHOD'] == 'POST'){ $errors = array(); // holds validation errors $data = array_map('trim',$_POST); // make a trimmed copy of all post data // check all required fields for being an empty string foreach($fields as $field => $arr){ if(isset($arr['required']) && $arr['required'] == 'y' && $data[$field] == ''){ $errors[$field] = "* {$arr['legend']} is required"; } } // all required fields have been checked for empty at this point, perform additional validation tests here... // you can add rules in the defining array, with things like regex patterns, php string filter function names... and have your code dynamically use that information to validate the fields as you simply loop over them, not hard-code logic for every input // at this point all validation tests have been performed. if there are no errors, you can use the form data if(empty($errors)){ // Insert your code for using the form data here, e.g emailing the submission, entering it into a database. echo 'Done using the form data'; } // if there are no form errors at this point, you would actually do a header() redirect to the same url that the form submtited to, in order to cause a get request for the page. this will clear the post data so that the browser won't try to resubmit the data if you refresh the page or browse back to the same url. // if there are form errors, you would continue on this page and let the following code run to display the form, populate the form with existing data, and display any errors. } // get request code would go here... if you are retrieving data to edit/update it, if the $data array doesn't exsit at this point, the form hasn't been submitted. retrieve any existing data and store it in the $data array. // produce the form, populating it with any existing data values, and display any errors ?> <form method="post"> <?php foreach($fields as $field=>$arr){ // note: this example is only for <input type='...'> fields. to address all the possible types of form fields, you would use a switch/case statement to output the correct markup for each different type echo "<label>{$arr['legend']}: <input type='{$arr['type']}' name='$field' value='".(isset($arr['value']) && $arr['value'] == 'y' && isset($data[$field]) ? $data[$field] : '')."'><span class='error'>".(isset($errors[$field]) ? $errors[$field] : '')."</span></label><br>"; } ?> <input type="submit"> </form>

i'm not sure why people keep writing-out/copy/paste/over-type line after line after line after line of repetitive code, for hours on end, that only differs in the the variables/names between lines of code in a section. programming is already a tedious task. creating all this repeating logic, unless you are using it to learn touch-typing, isn't an effective use of time and isn't using the computer as a tool to get a job done. dynamically get the computer to do this for you, by operating on the data as a SET by using php's array functions. define all the form fields in an array, with the form field name, label, the field type, choices for check boxes and radio buttons, validation rules, ... that would let you simply loop over the definition to produce the form and process the form data. an example of trimming all the form data at once, by treating it as a SET of data - $data = array_map('trim',$_POST); // get a copy of the trimmed data - and if you are submitting arrays of data, just make a call-back function and use array_walk_recursive() instead. this one line eliminates all those 20-40 sets of logic and eliminates all the typo's and checking to make sure you have logic for each input. just reference $data['form_field_name_here'] to use the trimmed data. dynamically reference any existing form data when you are looping over the defining array to displaying the form. dynamically reference any error array elements the same way. doing this also has the advantage of implement DRY (Don't Repeat Yourself) programming, because any particular code/markup will only exist once, so if you need to fix or change what it does, you only have to make the change in one place. once you have implemented this for one form, you now have a form-generator/processor that you can use to implement any form, simply by changed the defining array and changing any code that uses the submitted form data. you would even use the defining array to dynamically produce an INSERT query for a database design, the fputcsv() statements for a file based design, or build the message body for an email based design, all without writing out code for every value that's being operated on.

the undefined index errors are because your form processing code is running unconditionally, before there is any form data to process. your form processing code should be at the top of your file, before the <!DOCTYPE html> tag (so that any validation errors can be displayed when you redisplay the form) AND the form processing code needs to be inside of a conditional statement that's testing that a form has been submitted, so that the form processing code only runs when there is form data. edit: see the following post for a suggested code layout that will help make your code fool proof - http://forums.phpfreaks.com/topic/297824-database-issues-and-working/?do=findComment&comment=1519095

@benanamen, the problem isn't strict mode. it's because you don't put single-quotes around the place-holders in the sql syntax.

it would seem that you have removed the code you previously had that was setting the PDO error mode to exceptions. the false value being returned means that the execute statement failed and an exception wasn't thrown for the error. so, why did you remove (or not copy) the error setting you did have in your code?

this is why you should use the documentation to learn the basics. if you read the relevant sections of the php.net documentation for the PDO class, you will find the meaning of and see examples showing how to use each method. while slightly off topic, a person's age is not a fixed number, unless they are dead. you should be storing a person's date of birth, and calculating their age.

the capitalization of your column name in the database table probably isn't exactly - repair_id. The query won't produce an error if the capitalization in the query doesn't match the actual table definition, but the php code won't match the column name. if your php error_reporting/display_errors settings are actually turned full on, you would be getting an undefined index error message, unless this code is inside of a html tag or a form element, in which case the error message will only be seen if you do a 'view source' of the output in your browser.

are you sure there's data in that column in the database table? without an ORDER BY term in your query, that query is will return the first row that's stored in your table, which is not even guaranteed to be the first row you inserted, and which can even change if you optimize or backup/restore your data. i suggest you review all the posts in your last thread, so that you won't be writing and testing extra code trying to get and use data that you cannot guarantee the value of until after a row has been inserted into your database table.

the reason you are getting the wrong output is because you are trying to use the database methods in the pagination class to run your own data retrieval queries, inside of a loop, separately from the pagination query. the pagination class shouldn't be extending the db class, it should be dependent on the db class, so that you don't find yourself calling page methods that don't have anything to do with pagination. you also wouldn't be calling your own data retrieval queries, since that would bypass what the pagination is trying to accomplish. for pagination to work, you would build one query that gets the data you want in the order that you want it. the pagination methods would just query for and retrieve the correct logical page of data based on the page number that has been requested. to do what you are attempting using this code, you would build your one main query so that it gets the data you want and orders the rows by the stockin_id, so that rows having the same stockin_id value will be together in the result set.

there are at least three problems with your code - 1) if you are doing this for real, you would not delete any data. you would keep the data for reference. 2) you would not create a database connection, run the code within one function, and close the database connection. in fact, your code is including/requiring the same files multiple times and creating database connections in a ton of places. 3) you apparently missed post #7 in this thread. you CANNOT get the highest value from a database table, add one to it, and USE that value. you will end up with concurrent instances of your code using the same value.

you cannot get the current value of either an auto-increment or your own maintained column value, add one to it and use that value. you will end up with concurrent instances of your code that will use the same value. if you want to do this and have the displayed value be the one that gets used in the database, you will need to pre-insert a row, using an auto-increment field, get that row's id, then display that id and use it to UPDATE the row when the form is actually submitted. this will have an affect of empty rows/wasted ids if anyone doesn't complete the form. the correct method would be to NOT try to display this information in the form. after the form gets submitted and the data is inserted, you would then have the actual id that you can display/email to serve as a confirmation number.

the way to do inventory, is like a checking account or an credit-card account register. you store a row for each + or - transaction. the table tracking the inventory would hold the book_id (you would also have a 'book' table that holds the unique information about each book/title), user_id (who added or subtracted a quantity), the date-time (when the user added or subtracted a quantity), the quantity, and a memo/comment/status column. you would initially store a row for each book/title, with the a positive quantity of how many are on hand. the user_id for that row would be the admin/librarian that initially enters the information. if more books are ordered and added to the inventory, you would add a row with a positive quantity. when someone checks out a book(s), you would enter a row for each different book_id, with the quantity as a negative value. when they check in a book(s), you would enter a row for each different book_id, with the quantity as a positive value. to get the quantity on hand, you would use a query with SELECT SUM(quantity) .... .... GROUP BY book_id. if you are giving each book a unique id/serial number, you would still do the inventory this way, but you would have a separate row for each separate book, with a serial_number column to record exactly which book was checked out/in. the quantity column would then either be a 1 or a -1.