mac_gyver

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.

you can display the next probable id, but your code or the visitor cannot use this value, because if more than one instance of your form/page is being displayed at the same time, the value being shown will be same on all the instances of the form/page, but the actual value that gets inserted by the database will be different. so, the question is, why do you want to do this as it will just confuse the visitor with a piece of information that he doesn't need to know at the time the form is being displayed, if at all?

you are passing a string and an array containing a quantity into your function. that doesn't make any sense from a definition standpoint. these should just be two values. there's no point in the quantity being an element in an array. wouldn't you just pass in the book-name/book-id and a quantity? next, why are you storing the quantity in each row? if you are making a row for each book (30 rows for your stated example, 12 rows for your apparent test data), storing the quantity in each row isn't relevant. what data do you want to store in each row? finally, for what purpose are you doing this? if this if for an inventory system, you would want a single row holding the quantity, not a separate row for each copy of a book.

the browser should just be displaying the current state. the control over what happens should be by the server-side code, regardless of how many times the current state is requested/displayed. what exactly is occurring when a page gets requested/refreshed that is causing a problem? are you using post method forms to submit data, with one-use-tokens to prevent double-submission, followed by a header() redirect to the exact same url that the form submitted to, to cause a get request to display the current state?

the total quantity is a derived value. you should not maintain a value for it, but calculate it when needed. your cart appears to be storing the quantity of each item as the value for each array entry (and if it's not, that is how you should be storing the quantity for each item.) you can just use array_sum($_SESSION['cart']) to get a total count of things in the cart. using count($_SESSION['cart']) would tell you how many different items are in the cart. your class method doesn't use/need an input parameter. why are you defining and calling it with one?

based on what i learned about the code, i finally figured out what the OP is referring to in this thread. this is the reason why you need to write applications without it taking a wall of repetitive code and why you need to put comments in your code to document what it is doing, so that anyone looking at the code can figure it out. the select/option menu in question is letting the visitor select among the different costs, with the value='....' attribute being the actual cost. the missing $chosencost_1 variable is actually present, after the registration form has been submitted, because the form code is being included back into the Check_Registration_Form11.php page, which is where the $chosencost_1 variable is at. the reason you are likely getting a 1 for a cost value, is because whoever/a-bot-script that is submitting the form, has figured out that you are using the submitted cost, so they are trying to get a $1 bargain on a course. this code is completely flawed in how it is operating. the most direct fix would be to do the following - 1) only the course id, the value in $recid on the Course_Details page, should be submitted between steps (your course registration data structure should actually only store the course id, student id (the unique information about a student should be stored in a user/student table, not in the course registration table), and any unique information about each registration, but i doubt you are going to change your data to do it this way.) 2) any page that needs to use or display the course data should use the submitted $recid value (after validating it) to query for the course information on that page. 3) any cost section should use a type value that identifies a choice among the available different costs, not the actual cost value. the actual cost the code uses should take the submitted type and get the actual cost from wherever it is stored. you should also validate that the type that was submitted is available/valid for the user, using whatever rules you have. which begs the question - why is the user even picking what price he gets? shouldn't that be an administrative choice, not a user accessible choice? 4) you should pass a minimum of information between pages in the form and any information you do pass through a form must be validated at each step. you may want to consider using a session variable to hold an array of the validated data so that you don't need to re-validate the data at each step.

@benanamen, it's against the forum rules to solicit work, except in the freelancing/services-offered forum section.

went through the code trying to figure out the program flow. here's some notes - Course_Details11.php - this page receives an id as an input, uses that id to retrieve and display the information for the course the id corresponds to. if the visitor chooses to register for the course, about 40 pieces of course information are passed to the next page as get parameters in the form's action='....' attribute. the only post data is the submit button. Registration_Form11.php - this page copies/validates/casts the data from the course_details page (18-19 items out of the 40 that are put into the url), puts this data (~11 items) into hidden form fields (without any html encoding, which may be why some form values don't work, if the values/upstream-values contain any quotes, breaking the html syntax), displays the user form fields, with any validation errors (see the check_registration_form notes next), and submits to the Check_Registration_Form11.php page. Check_Registration_Form11.php - this page copies/validates/casts ALL (hopefully, didn't bother to count the hard-coded line after line of code) the data from the registration form page. if there are validation errors, it includes the registration form page (which is a complete html document itself, giving two nested documents at this point) so that the form and any errors can be displayed. since there is no specific form processing conditional statement in any of this code, doing the include, causes all form processing/form display logic in the registration page to run again. if there are no validation errors, some/all of the data is saved in a 'Online_Activity' database/table, but this isn't used by the code to save on passing data to the next step. the user data is displayed as a conformation check and ALL the $_POST data (this time with html encoding, though not with all quote types encoded, which is amazing because the display section is using html encoding with all quote types encoded) is put into hidden form fields for the next page. to correct any data, you must use the browser's back button. this page submits to the process registration page. Process_Registration11.php - this page validates JUST the original course_details data (19 items). it doesn't validate the user entered data. it finally saves the data to a 'Web Registration Information' database/table. then sends some emails, and updates some more database information. @ the OP, if this is something that is actually being used for registration at a school, and it is beyond your abilities to find and fix the problem among the wall of 6800+ lines of uncommented code, you should expect to hire someone to fix this for you, rather than to get free programming services on a programming help forum.