mac_gyver

if your code isn't using the database, those lines of code would have no affect on what your code does. however, if you are using a database, there are some inconsistencies between running an emulated prepared query and running a real prepared query (thanks php) that could be throwing an error, and depending on how you are handling any thrown errors, combined with the error_reporting level you have set in your code, could result in your code halting without showing any error information. don't set error_reporting to zero. it should ALWAYS be set to E_ALL. when debugging problems, you should display errors (set display_errors to ON), otherwise they should be logged (set display_errors to OFF and set log_errors to ON). also, don't use output buffering statements in your code unless you ARE buffering output. they hide messages from your code and php error messages.

the php.net documentation has migration sections in the appendix that lists the major changes that have been made to the language. if your code is dependent on any of the Backward Incompatible Changes, from the starting php version you were using to the final php version you have now, you will need to rewrite that portion of your code. we cannot specifically help you since we don't know what exact method, among all the possibilities available in programming, your code is using. you would need to post enough of your code that reproduces each problem to get specific help.

you would use an UPDATE query with a WHERE clause to control which rows get updated. the following is the UPDATE query syntax definition of the commonly used parts highlighted -

you are missing a $stmt->fetch(); method call to retrieve the data. the PDO extension is much more consistent and straight-forward to use, particularity with prepared queries. if you can, switch from using the mysqli extension to the PDO extension.

you don't even have any code to move the uploaded file in the NEW RECORD logic. are you looking at your code at all? you shouldn't be duplicating the code between the EDIT RECORD and and the NEW RECORD logic. the only thing that's different is the UPDATE query, when you have an id, or the INSERT query when you don't. you should have ONE instance of the logic, then a simple conditional if/else branch to form either the UPDATE or the INSERT query, then back to ONE instance of the logic to execute the query.

this would be another good reason to ascend to a higher plane of programming existence and reuse proven, tested, general purpose code. so that each time you do the same thing, you don't have to beat on the keyboard typing out bespoke code and queries, then find and fix all the typo's and missing or wrong statements. reusing proven, tested, and general purpose code will let you concentrate on the program flow and the goal you are actually trying to accomplish, rather than on the tedious details of each step you take along the way.

there's two reasons you are getting an error at the ->execute() method call - 1) emulated prepared queries are on by default (and not well documented, thanks php). meaning, you are not running real prepared queries. the ->execute() method is forming the complete sql query statement, with the bound data inserted into it, then calling the ->query() method internally to execute the query. when you make the database connection, you need to set emulated prepared queries to false. add this line after the connection - $conn->setAttribute(PDO::ATTR_EMULATE_PREPARES,false); // run real prepared queries and you might as well do something else i stated and add this line - $conn->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE,PDO::FETCH_ASSOC); // set default fetch mode 2) the error you are getting should contain information about an sql syntax error (type, the name of one of your columns, is a reserved keyword), though the error information at the execute() method is sometimes lacking, more than normal..once you set emulated prepared queries to false, you will be getting an explicate sql syntax error at the ->prepared() method call. you should avoid using reserved keywords as database, table, and column names, but if you must, you can add back-ticks around the $field name in the following line of code (in each place the query is being prepared, or in one place, if you make the general purpose prepared query method as suggested) - $and_terms[] = "`$field` = :$field"; by removing the name='submit' from the submit button in the form. for a get method form, there's no need for a name for the submit button. the form field data will either exist or it won't and your code just needs to check for the field data, not a submit button. you also need to remove the if(isset($_GET['submit'])){ and the matching } from the code. and remove the three lines of code that are right after the if(isset($_GET['submit'])){ statement.

the OP's code is actually setting a default value of 1, if there is no page get parameter, validating the value as an integer (within php's integer range), and is limiting the value between 1 and the total number of pages. don't copy or use code unless you understand it. this bit of code is repetitive and unnecessarily bespoke/hard-coded, and isn't using the correct entity version of an & for links on a page. your code still has a number of unnecessary and problematic things in it, which i am betting you have been informed of most of them in previous threads - 1) use the correct input variables where you expect the data to be. use $_GET, not $_REQUEST. 2) i don't know what your clean() function code is, but i'm betting it isn't effective and is best left out. 3) the try/catch block will catch errors with the prepare/execute methods. this means that there was a sql syntax error or wrong bound parameters. this does not mean that the query ran, but didn't match anything. there's no need for a local try/catch block unless you are specifically handling a type of query error in your code, such as a duplicate key error from and INSERT/UPDATE query. 4) the global keyword only has meaning when used inside a function definition and even there it indicates bad coding. don't use global $var_name; 5) the code to build the WHERE term for the sql query statement should not be repeated. build the term in a variable, then use that variable each place it is needed. 6) the external data you are putting into the WHERE term needs to be handled using a prepared query with bound input parameters. 7) the $start and $end variables are not used in the posted code and should be removed. the sql query statements should be built in a php variable, this supports debugging (you can echo/log the statement, though the pdo statement object has a queryString property you can use) and it leads to writing general purpose code. 9) you need to set the default fetch mode in your connection code, so that you don't need to specify it every time you run a query. 10) the pdostatement object is already traversable. you don't need and shouldn't be applying the new IteratorIterator() to it. 11) for queries that will return a set of data, just fetch all the data using the fetchAll() method. you can then use count() on the data to find how many rows the query matched (the ->rowCount() method doesn't work with SELECT queries for all database types, so, using fetchAll()/count() will work regardless of which type of database you are using.) 12) to produce the pagination output, you need to test how many pages were calculated, not if the data retrieval query returned any rows (there's a condition that's mentioned in the code where you would need to produce the pagination links even if the data retrieval query didn't match any data) 13) your <span> tags are reusing the same id='...' value, which is invalid. if you are doing something unique with each span (which is doubtful), you would need to use unique id values. if you are not doing anything with the span, don't include it in the markup. the following example code shows how you might do this. this code adds the following features - 1) shows how to do a data driven design, where you define somewhere (an array or database table) a set of data that general purpose code operates on. this eliminates repeating block after block of same functioning code. this also has the benefit of helping to implement DRY (Don't Repeat Yourself) programming, since it eliminates the repetitive logic. 2) it implements the suggestion of leaving a particulate field out of the sql query statement when it is the 'ALL' choice or when the choice isn't present at all in the $_GET parameters. 3) shows how you would apply http_build_query() when building each link. // define the possible search fields - this is used to produce a data driven/dynamic design, where you don't write out block after block of code that only differs in the value it operates on $search_fields = array('title','name','description'); $and_terms = array(); // WHERE terms to be AND'ed $params = array(); // bound input parameters for a prepared query foreach($search_fields as $field) { if(isset($_GET[$field]) && $_GET[$field] != 'ALL') // only if the field is set and it's not 'ALL' { // add the search field to the WHERE terms $and_terms[] = "$field = :$field"; $params[] = array(":$field",$_GET[$field],PDO::PARAM_STR); } } $where_term = ''; if(!empty($and_terms)) { $where_term = "WHERE " . implode(' AND ', $and_terms); } // get the total matching rows $query = "SELECT COUNT(*) FROM table $where_term"; // note: the following logic should be in a general purpose prepared query method that you extend the PDO class with if(empty($params)) { // no bound inputs, just execute the query $stmt = $db->query($query); } else { // there are bound inputs, produce a prepared query, bind the inputs, and execute the query $stmt = $db->prepare($query); foreach($params as $param) { $stmt->bindValue($param[0],$param[1],$param[2]); } $stmt->execute(); } $total = $stmt->fetchColumn(); // calculate total number of pages $pages = ceil($total / $per_page); // limit the page number $page = min($pages, filter_input(INPUT_GET, 'page', FILTER_VALIDATE_INT, array( 'options' => array( 'default' => 1, 'min_range' => 1, ), ))); // calculate starting row for LIMIT $offset = ($page - 1) * $per_page; // add limit values to the array of bound parameters $params[] = array(':per_page',$per_page, PDO::PARAM_INT); $params[] = array(':offset',$offset, PDO::PARAM_INT); // query for the data $query = "SELECT * FROM table $where_term ORDER BY id DESC LIMIT :per_page OFFSET :offset"; // note: the following logic should be in a general purpose prepared query method that you extend the PDO class with if(empty($params)) { // no bound inputs, just execute the query $stmt = $db->query($query); } else { // there are bound inputs, produce a prepared query, bind the inputs, and execute the query $stmt = $db->prepare($query); foreach($params as $param) { $stmt->bindValue($param[0],$param[1],$param[2]); } $stmt->execute(); } $result = $stmt->fetchAll(); if(!count($result)) { // query didn't return any row(s) - this doesn't mean there isn't any matching data, just that the query for the requested LIMIT range didn't return anything (there's a race condition, where if data gets deleted between the COUNT() query and the data retrieval query, queries for data near the end can return nothing) echo '<p>Nothing found.</p>'; } else { // query matched one or more row(s), display the data foreach ($result as $row) { echo $row['id']; } } // if there are any pages, display the pagination if($pages) { echo '<div id="pagination"> <div id="pagiCount">'; $q = $_GET; // get a copy of any existing $_GET parameters - do this once before the start of your pagination links $prevlink = ''; if($page > 1) // not on the first page { $q['page'] = 1; $qs = http_build_query($q,'','&'); $prevlink = "<a href='?$qs' title='First page'>First</a> "; $q['page'] = $page - 1; $qs = http_build_query($q,'','&'); $prevlink .= "<a href='?$qs' title='Previous page'><<</a>"; } $nextlink = ''; if($page < $pages) // not on the last page { $q['page'] = $page + 1; $qs = http_build_query($q,'','&'); $nextlink = "<a href='?$qs' title='Next page'>>></a> "; $q['page'] = $pages; $qs = http_build_query($q,'','&'); $nextlink .= "<a href='?$qs' title='Last page'>Last</a></span>"; } echo "<div id='paging'><p><small>$prevlink Page $page of $pages $nextlink </small></p></div>"; echo '</div></div>'; }

you need to build the query string part of the url (the part after the ?), using http_build_query() and any existing $_GET parameters - $q = $_GET; // get a copy of any existing $_GET parameters - do this once before the start of your pagination links // when you build each link - first, last, previous, next do this - $q['page'] = // set the page value to the value you want for the link you are building from whereever the code is getting the value now $qs = http_build_query($q,'','&'); // build the query string part of the url echo "<a href='?$qs'>the label you want for the link you are building from whereever the code is getting the lable now</a>"; // output the link

Assuming the $alev array and the php code/html markup you have posted is accurate, the problem is in the code that's producing the comma separated value you are storing into the database table, which as already stated, you should not be doing anyway.

you are probably storing some white-space in with the data, which you should be storing not as a comma separated list, but as a separate row in the table for each check box that's checked. what exactly does the $row['hw_lev'] look like using var_dump($row['hw_lev']);

A TEXT column has a maximum length of 65,535. php's mysql extension, i.e. the mysql_xxxxxx() functions, are obsolete and have been removed from the latest php version. the PDO extension/class (which is the best choice to use as a replacement) and the mysqli extension/class (turns out is not the best choice to use, thanks php) are the available replacements when using php with a msyql database. the problem you are currently having may be triggering an error, and having error handling in your code for the execution of the sql query would result in useful information being produced. you ALWAYS need to handle any errors that statements can produce. when debugging problems, you would want to display errors. on a live server, you would want to log errors. the switch between displaying and logging errors can be done automatically if you use php itself to handle the errors, since php's display_errors and log_errors settings will control what happens with the error messages. you would also need to set php's error_reporting to E_ALL, in both cases, so that all errors will be reported. the easiest way of handling errors is to use exceptions, which both the PDO and msyqli extensions/classes supports. if you are going to use the PDO class, you would set the error mode to exceptions, either in the connection statement or as a separate statement right after you make the connection. if you don't catch exceptions in your code, using a try/catch block, php will handle the uncaught exception and produce a fatal error that contains the actual error information. some other things to configure for the PDO connection - 1) set the character encoding of the connection in the connection statement. 2) set emulated prepared queries to false. 3) set the default fetch mode to assoc, since this will (should) be the most common usage in your code. next, you need to use a prepared query to supply input data to an sql query statement, by putting place-holder(s) into the sql statement where the data is to be used and binding the data to the place holder, either explicitly (which is the best general choice) or implicitly (doesn't work in some cases since all data is treated as a string), and supplying the actual data separately for the execution of the prepared sql statement. using a prepared query will ELIMINATE the need to escape string data, which my also be where the current problem is at. your current code is ineffective as escaping data (there would be a query error, from the error handling), since you are first escaping the data, then undoing that escaping with the stripslashes() statements. the problem is more likely because your longer text has sql special characters in it, such as a quote.

you can get the last php error information using - error_get_last() (returns an array of information.). you can also get the last php error message in $php_errormsg, but this also requires that the track_errors setting be set to an on/true value, which you can set in your script.. the phpmailer class has an $ErrorInfo property that would give your script information about the last error that occurred.

in addition to what has previously been listed, here are some specific things this code needs to do or do differently - 1) your search form should use method='get'. a get request should be used to cause your page to display whatever it is designed to display. a post request should only be used to alter (create, update, delete) data values on the server. the programtype, country, and sorthow values should all be carried in the url. this will eliminate the logic at the top of your code for the programtype. you should however ALWAYS validate that programtype (all input data) is a permitted value before using it. 2) don't use $_REQUEST. use the correct $_GET, $_POST, or $_COOKIE variables where you expect the data to be. for what this code is doing, all inputs should be in and use $_GET. 3) the php code that determines what to do on the page, validates inputs, and forms and run sql queries to retrieve data to display on the page should all be grouped together and come before the start of your html document. this will make it easier to write and test your code and to change the database extension that it uses. this code is commonly called the 'business logic.' the result from the business logic would be php variables. the html document would just use the data that's in the php variables. it would not contain any database extension statements. 4) the sorthow select/option menu should be 'sticky' and select the option that was previously picked. if the sorthow value is being used to find data, the way you are putting it into the sql statement won't do anything useful. you are putting a literal string value into the WHERE clause WHERE 'a string' ... if it is being used to produce an ORDER BY ... term, you would need to validate that it only contains a permitted value, you would also need either an ASC or DESC sort direction. then produce the ORDER BY ... part of the sql statement.

since the purpose of this form is to INSERT new data, there's no point in having the check-box as part of the form data. if what you are trying to do is to have one form that works for inserting new data and updating or deleting existing data, you would use a completely different set of array names for the new/dynamically added fields (what you have now) and for the fields for existing data. the fields for existing data would use the id from the database row as the form field array index value. you would process these separately, inserting new data and either updating or deleting existing data. also, you have made the check-box 'required', so, you cannot submit the form, using current browsers, unless all of the boxes are checked. your javascript logic is the reverse of this. you must check the ones to remove and un-check the ones to keep, but then the form won't submit unless you check all the remaining boxes. if what you are trying to do is allow for a row(s) of the dynamically added form fields to be removed, there are two straight-forward ways - 1) only use the check-boxes to control what the 'Remove Attributes' button operates on. don't pre-check the check-boxes and don't make them 'required'. you would check any boxes you want to remove, then click the 'Remove Attributes' button. 2) add a 'Remove' button at the end of each dynamically added row, that just removes that row from the DOM.

i was going through this terrible brute-force-built phpmotion code, trying to figure out what it thinks it is trying to do (i do know what it is trying to do, the Author wasn't so clear on this), and i found why it doesn't work for the validation errors. sorry for the commentary, but this code is so bad and repetitive, i got dizzy looking at it. there's 370 lines of bad code that it would take about 150 lines of good code to accomplish the same thing. the die_with_msg() function is trying to load the template file, but it is referencing the $user_theme variable to form the path. that variable doesn't exist inside the die_with_message() function. there would be a php error about the undefined variable, if php's error reporting was turned fully on and if you turned on the template error setting, you would get an error about not being able to load the template. these same messages either don't work at all for both the original location of the files and the copied location of the files OR you have some sort of symbolic path setup or you have previously duplicated some of the template files, so that the path produced by the missing $user_theme variable matches an actual path for the original location of the files, but not the copied location of the files. so, why are you actually moving these files? if you want to change/test the functionality of the form processing code, you would make a copy of the .php file, in a different location, but use the same template in it's original location. you could actually just make a copy of the .php file in the same location with the original file, but with a different name, but you would need to remove the action='upload_avatar.php' attribute. no action attribute or an empty value submits to the same url that the form is at.

what do you get in your browser for the cases where it doesn't work? and if you get a blank page, what does the 'view source' of the blank page show? what folder(s) exactly did these two files start in? the .php code is looking in a relative folder path - "themes/$user_theme/templates/"; to find the template file. unless you moved (or did you copy it, leaving the original where it was) the template to a new location that has that exact same relative path structure, this shouldn't be able to even display the form. edit: the reason you are not getting anything in the application's log file is because it uses a relative path in the code and when you moved the .php file, it broke the path. there would be php errors about this if php's error reporting was turned full on.

afaik, only database names and table names are ever case sensitive, on case sensitive operating systems. column names are not and referencing a column in a query using a letter case that doesn't match doesn't throw a query error (it would be a problem when trying to fetch the data since the actual column name letter case is what would be present in the data.) what does the result of running the query - SHOW CREATE TABLE `mylogin` produce? add the following to the list above - 19) you should be using php's password_hash() and password_verify() for hashing/testing the hashed password.

first, here's a list of things to consider - 1) all the form processing code needs to be inside the conditional statement that controls the execution of the form processing logic - if(isset($_POST['some_field_name_here'])){ all form processing code goes here... } 2) you should test a (hidden) form field that uniquely identifies, either by field name or the value in a field, which form submitted to the form processing code. 3) if the current visitor is already logged in, you would skip/prevent displaying the registration form and processing the registration form data 4) avoid using the _once form of the require statement. your code should be organized, so that you know when and where it is requiring files and you don't need to use the _once form. php has also had a number of bugs with the include path and correctly resolving the actual file so that the _once part actually works one time. 5) i recommend NOT using UPPERCASE for most things in your code and database queries, i.e. your form field names and database column names should be lower case. only use uppercase when you are calling attention to something. a convention is to use uppercase for defined constants, so that they stand out from any code/text they are surrounded by, and for parts of sql query syntax, i.e. SELECT, FROM, WHERE, ... 6) all your header() redirects need an exit; statement after them to prevent the code from continuing to run. the header() doesn't stop program execution. 7) you should use an array to hold validation error messages. this will let your code detect and display more than one validation error at a time. if only some of the required form fields are empty, one of the other fields doesn't contain an expected value, and the username or email is already in use, you would want to display all these errors at once. the captcha check should make sure that there is a $_SESSION['code'] value and that it's not empty 9) you should validate each 'required' input to insure that it contains either an expected/permitted value or format. 10) you should produce a separate and unique validation error message for each possible validation problem, i.e. don't combine all the empty() checks into one message. 11) you should trim all input data before using it. this will eliminate leading/trailing white-space characters. if you want to allow leading/trailing white-space characters as part of a password, exclude that from what you trim or get an untrimmed copy of the original $_POST data when using the password value. 12) your current code requires the captcha to match before doing any other processing. after making the suggested changes, it should still do that and skip all other processing, even the database connection, if it doesn't match. 13) whenever possible, dynamically process sets of data. your form fields are a set of data. you should avoid writing out line after line of code, repeated for each different form field. because the $_POST data is an array, you can use php's array functions on it when performing the same operation on each field. to do this, you would make an array of the form field names, then loop over this defining array and access the corresponding post data. you can expand on this and dynamically produce the form by including things like the form field type, label for the field, ... in the defining array. 14) only escape data right before using it in an sql query statement (or even better, use a prepared query with bound input parameters.) 15) it's unfortunate that you picked the mysqli extension, rather than the PDO extension. the PDO extension is more constant, easier to use, and has fewer gotchas then the msyqli extension, especially if using prepared queries. 16) running a SELECT query to test if the username/email is already in use allows a race condition where concurrent visitors can try to INSERT the same values. the fix for this is to have those two column defined as UNIQUE indexes, then just run the INSERT query and use the duplicate key index error information that will occur to tell the visitor that the username or email is already in use. the duplicate key error will report the first key that's duplicated, so, if someone does happen to repeat both values, it will take two form submission to detect this OR you could run a SELECT query after the INSERT query to find which or both of the values are duplicated. 17) if you put the form processing code and the form on the same page, it will eliminate all the session variables/header() redirects. the only place you would need a header() redirect is after you have successfully (no errors) processed the form data. you will also be able to repopulate the form fields (except you shouldn't repopulate the password field) when there is a validation error, rather the require the visitor to keep typing in the same information over and over. 18) after successfully, no errors, processing the form data, you should do a header() redirect to the exact same url that the form submitted to. this will cause a get request for the page, which will prevent the brower from throwing an error or trying to resubmit the form data if you reload the page or browse back to the url of the page. as to why your db column name in your sql query statement doesn't match your table definition, i'm betting that your actual db column name isn't spelled exactly as you are using it in the sql query statement.

here are three important things to do when learning php, developing php code, debugging php code, or asking for help with php code - 1) we are not sitting there with you. we don't know what you saw that leads you to believe that something didn't work. you mentioned that the $query fails, but you didn't state what error/message or symptom you got that leads you to believe that it failed. tell us exactly what did happen. 2) you need to set php's error_reporting setting to E_ALL and the display_errors setting to ON, in the php,ini on your development system, to get php to report and display ALL the errors it detects. putting these two settings into your code won't help with syntax errors in your main file since your code never runs in this case. you should also turn off php's output_buffering setting in the php.ini, since it hides problems in your code and you should only use output_buffering when you want to buffer output. 3) your code needs to ALWAYS test for and handle errors that can occur with statements. When developing and debugging code, you would display the errors, when running code on a live server, you would log the errors. by testing for and handling errors, your code will tell you when, where, and give you information about why it is failing. if the error you are getting is your 'failed' message, having error handling in your code for the database statements would tell you why the query failed. in one of your previous threads, you were told to use msyql_error() to get query error information. wouldn't that same advice apply, but using the equivalent mysqli statement? note: mysqli_error(....) statement requires the db connection link as a parameter. the type of error handling you can use is dependent on what sort of statements you are using. the best choice is to use exceptions to handle errors. the mysqli statements you are using do support exceptions. assuming you have set php's error settings as suggested above, add the following two lines of code before you make a database connection, so that a connection error will also throw an exception - $driver = new mysqli_driver(); $driver->report_mode = MYSQLI_REPORT_ALL; // <--- w/index checking; w/o index checking ---> MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT; this will throw uncaught exceptions for the msyqli statements. with the php error settings that have been suggested, php will report and display the error information. on a live server, you would instead log the error information. if i/others have time, i/we will make a list of things your code needs to do or do differently.

that will fix the immediate issue of the simple html dom class not running, when it's not where the error is at. any php error, no matter how benign, prior to using the load() method, will cause this problem. you should be defining/assigning the first line to the variable before using a concatenate operator on it anyway. every error in your code, even if the reporting/display/logging is turned off, is still being detected and handled by php. the reporting/display/logging is just the last step in the php error handling.

the OP's script is (he posted the code on one of the many forums he is asking this on) the phpmotion video/image/audio/blog/group sharing script. the information for each 'type' is stored in a different table with a few different column names/meaning between the tables and there's a switch/case statement on the type value to determine what columns to select and to select a table name where the related comments are stored, which are accessed by running another select query inside of a loop. this script looks like it is basically five independent scripts that were forced together. most of the code in the search.php file is so bad and out of date (@ error suppressors, ereg, msyql statements, string escaping things that aren't strings, no validation of the type value - you can enter a value that's not one of the choices and trigger all kinds of errors...) that it wouldn't be worth anyone's time trying to make to work. @Chrisj, if you want to have an 'ALL' search choice, you need to start with a script that properly stores the primary and related data in a normalized fashion. If the original Authors of this script had done this, there would be very little program logic present and doing the things that have been suggested, which assume that the type choice is just a value in a column in one single table, would be simple. edit: this script is also using an equally bad template system called TBS (Tiny But Strong), which i think was authored by the same people as the phpmotion script.

actually, there may (untested) be a way to do this through the browser. at least the chrome browser, has a command line parameter that allows local file access. it's intended to allow local testing, where things like an ajax request would make use of a local file. when used, this applies to any url the browser requests, so you would only want to do this for your site, so as to not allow any other site access to files on the local pc. you would make a desk-top short-cut that invokes the browser with the correct command line parameter and only use this when visiting your site. i don't know if the 'same origin' policy would override this, since the web page is coming from a different address than the local usage in the code. assuming all this actually works, the client-side code on the page could make an ajax request to read the local file, then submit the data to the remote server in a post request. this sounds like a good phpfreaks programming challenge to see if anyone can come up with working code and for which browsers it would work.

you cannot automatically upload a file from the client/local pc to a remote server using a script running on the remote server, without having some software running on the client/local pc. the script running on the remote server does not have any access to the files on the client/local pc, either through the browser or via any communication protocol. to do this, you first need to pick a protocol. ftp, http, or ssh would be the available choices. you would then need to install server software on the client/local pc, either an ftp server, a http server, or an ssh server. you could then have a script running on the remote server connect to the client/local pc and upload/copy the file.

to save anyone from wasting time replying with problems in this code, the OP has already been told - 1) what the main problem is, which should be enough to make the code 'work', especially if he is aware of or is looking at what data is being storing in the database tables, which, sorry for the cutting commentary, the OP apparently isn't aware of or looking at. 2) to use the id of the source data when storing related data in other tables, i.e properly implement the R in RDBMS. 3) to have an exit statement after the header() redirect. 4) about the obsolete mysql statements, and to use PDO with prepared queries to securely get data values into the sql query. some other things to mention are - 1) don't include your database connection file more than once in the code. 2) separate the database code, that's retrieving data, from the presentation code, that's using the data to produce the output. doing this will actually make it easier to rewrite the code to replace the mysql statements with something more current.