mac_gyver

just because mysqlnd is installed, doesn't mean that the mysqli or PDO extension will use it. your installation of php would need to be compiled with switches set causing the mysqli and/or PDO extensions to use the mysqlnd driver. there would be mysqlnd entries shown in the client api sections of the msyqli/pdo_mysql phpinfo output. if the script cannot be easily switched to use the PDO extension, you may (untested) be able to conditionally detect the existence of the get_result() method and extend the mysqli stmt class with a user written method that returns an instance of a user written class that emulates the features of a mysqli result class that the script is using (afaik, it is not possible to create and return an actual populated instance of the built-in mysqli result class). this of course is just a kluge. the whole php mysqli prepared query implementation is bad, and this is just one more case highlighting that it should not be used.

the HEREDOC ending tags ( END_OF_TEXT; in your code) must start in the 1st column and be the only thing on the line. it's not clear if what you posted was the result of how you added the line numbers or if you actually have some white-space ahead of the Heredoc ending tags. you also have at least one weird single-quote, in front of the l_name array index, on about line 122, that needs to be a simple single-quoted - there's a missing single-quote on about line 140, ahead of the state array index name - there's another weird quote on about line 175, ahead of the add_type array index name - and there's more after that point, but i stopped looking. you can find these type of things by looking at the color highlighting, or lack of, in your programming editor. at each of these, the color highlighting stopped changing at that point. edit: here's some more suggestions - 1) use exceptions to handle database statement errors. this will eliminate all the logic from the code that's testing if the queries (and connection) worked. 2) use prepared queries. this will eliminate all the mysqli_real_escapes_string function calls from the code and all the extra variables being used to hold the escaped data. 3) if you are building a double-quoted php string, rather than escaping double-quotes within the string, just use single-quotes within the string. 4) you can put php variables directly inside a double-quoted php string. no need for a bunch of concatenation dots. these things will greatly simplify your code, so that you/we/i can see what it is trying to do.

if c1, c2, and pk in your example are the only columns, you can use a multi-value REPLACE query, otherwise use a multi-value INSERT ... ON DUPLICATE KEY UPDATE .. query (which, since the the data already exists, implements a multi-value UPDATE query). the max packet size refers to the data sent in each communication back and forth between php and the database server. for a true prepared query, the sql statement (which is a string) would be sent in one communication, and the data for each execute statement would be another communication. named place-holders are implemented solely in the php PDO driver. the actual sql statement that is sent to the db server has had them replaced with ? and the driver maps the names to the place-holder parameter number when it builds the communication command to send the data to the db server - here's an interesting read on what the binary transfer protocol is for the execute statement when using prepared queries - https://dev.mysql.com/doc/internals/en/com-stmt-execute.html#packet-COM_STMT_EXECUTE note: the binary transfer protocol is only available when using prepared queries and then it only really saves time if transferring binary data. for string data values, which is the default for PDO, unless you specifically bind the data using a non-string data type, the data is still sent as characters and there's no time savings in the communication. and here's the reason for the performance difference - for simple queries, the communication time (handshaking + actual transfer) for both the prepare() and execute() statements is much greater than the time to actually prepare (parse/plan) or to execute the query on the database server, so, from the php side, the only way to significantly reduce the amount of time taken is to reduce the number of separate communications. running a single row prepared query inside of a loop only saves about 5% (bench-marked using a mysqli prepared query a while ago) of the overall time, compared to running a non-prepared query inside of a loop, because all you have eliminated from the loop code is the communication of the sql statement string and the parse/plan step. you are still performing a separate communication for each pass through the loop and have to spend the time for the handshaking + actual transfer for each communication. the only signification time savings i have seen is when using a multi-value query, which Barand has also confirmed in his tests. to fully implement a bulk method, figure out the maximum number of data values you want to send at once. if the actual amount of data is less then the maximum you have chosen, dynamically produce the multi-value sql statement of your choice for that amount of data, prepare it, then supply the data as an array to the execute statement. if the actual amount of data is greater than the maximum you have chosen, break the data into equal size blocks that are less than the maximum. if there's an odd amount of data, you can include one dummy/repeat set of values to make all the blocks the same size. then, dynamically build the multi-value query statement with the correct number of sets of place-holders to match the block size, prepare the query, then loop over the actual data and break it into arrays of the correct size, fixing up the size of the last block if it is odd, and supply each array of data to the execute() statement.

another point about prepared queries, you prepare them once, then can execute them multiple times. the UPDATE query should be prepared once, before the start of the loop. the code inside the loop should only populate the data for the place-holders, then execute the query. @NotionCommotion, the OP's from and to values do make sense. from is an older date and needs to be the first parameter in the BETWEEN term for the statement to work. to is a newer date and needs to be the second parameter in the BETWEEN term.

do you have php's error_reporting set to E_ALL and display_errors set to ON in the php.ini (putting these settings into your code won't help show syntax errors in the same file where the settings are being set) on your development system so that php would help you by reporting and displaying all the errors it detects? you would be getting a php syntax error because you are mixing php and html markup inside of php code tags. you would also be getting a blank php page, which you didn't tell us you are getting as a symptom when you run your code. to output in-line html markup, you need to have a closing php tag to switch out of php 'mode'. with 300+ posts, you should be past having these basic problems.

example of the array/flag method, that has the added advantage of separating the database specific logic from the presentation logic, so that if you do end up with a correctly designed database table, you only have to change the database specific logic. the presentation logic would remain the same. if (isset($_GET['zoeknummer'])) { $pdo = new PDO("mysql:host=$dbhost; dbname=$database", $dbuser, $dbpass); $pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); $pdo->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC); $pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false); $sql = "SELECT lead_content FROM wp_wgbsupicrm_leads"; $res = $pdo->query($sql); // where $pdo is your db connection $matches = array(); // array/flag to hold the matching data while($lead = $res->fetchColumn()) { $data = json_decode($lead); if ($data->zoeknummer == $_GET['zoeknummer']) { $matches[] = $data; } } // presentation logic - produce the output from the data if($matches) { foreach($matches as $data) { echo "Uw plaats voor " ; echo $data->wachtlijstkomplex . ' : ' . $data->wachtlijstplaats . '<br>'; } } else { echo 'Geen resultaat gevonden met opgegeven nummer. <br> Kijk na of U het nummer correct heeft ingevuld.'; } }

if you are not tied to this database design, you should change it to properly store the data. by storing json encoded data, you cannot directly find matching data using the sql query. this will also not scale well as you must retrieve all the data in order to scan it for matches. this will result in a poorly performing web site when there is a moderate to large amount of data. if the data is stored properly, by storing the 'columns' in the json data in individual database table columns, you can find the row(s) that match the search term, directly in the sql query statement and all the code will be simplified. for your current design, the easiest way of using the FLAG method would be to use an array and store any data that matches the search term into the array. after you finish looping over the data, if the array is empty, there were no matches. if the array is not empty, loop over the entries in it and produce the output from the data.

please, don't try to store data into a database table like it is a spreadsheet. each data item should be stored in a separate row in the table. your table should have columns for KODARTIKULLI, KODNIVELCMIMI, and CMIMI. next, you don't have to try to select data (which you are not actually fetching and storing the count into a php variable in your code) to determine if you are going to insert a new row or update an existing row. there's a single query that does that - INSERT ... ON DUPLICATE KEY UPDATE ... the KODARTIKULLI and KODNIVELCMIMI columns would be defined as a composite unique index to both enforce one row per combination of those values and to allow this query to work. you should be using a prepared query in any case, but using one when running a query inside of a loop will result in the most efficient operation (saves some time in the parsing and planning of the sql statement). the query would be prepared once, before the start of your loop, with place-holders in the sql statement for the data, then the data would be supplied to the sql query statement when you execute the query inside of the loop. unfortunately, the php mysqli extension is not the best choice to do this. if you can you should switch to use the php PDO extension. in short, all the code and queries you have shown can be replaced with just a few lines of code and one sql query statement.

putting the error settings in your file won't help with php syntax errors in the same file because the code never runs to cause the settings to take effect. you need to put these settings into the php.ini on your development system, which may require restarting your web server to get the changes to take effect. BTW - the currency symbol should not be stored with the price (hint as to where at least one error is at). it is a display property and should be handled when you display the price, not when you store the price.

vague comments about not having any luck with something don't tell us anything useful. there are varying levels of luck and unless we know what your standard is, we don't know what result you are getting. communicate exactly what is happening and if it's not blatantly obvious what's wrong with the result, tell us what's wrong with the result and what result you expected. do you have php's error_reporting set to E_ALL and display_errors set to ON (preferably in the php.ini on your development system) so that php would help you by reporting and displaying all the errors it detects? by default, you cannot use a URL with file_get_contents(), and there would be a php error alerting you to this issue.

how do you know the email is not being sent? what exact symptom, error, or output are you getting from your code and what output did you expect? where in the posted code are you echoing the message at? how do you know that the $email isn't somehow satisfying the mail() function. there are many levels of satisfaction and unless we know your standard, we are left guessing what that statement means. short-answer: were are not there with you and don't know what you saw when you ran your code. the information you supply must concisely communicate what did happened, what should have happened, and for the case of echoing things in the code, post that code, not some other code.

since you didn't address each of the points/questions i ask, it's not going to be possible to directly help you, since we only see the information that you post. these are some more points, from your last thread - i'm betting your posted code is either not being executed due to conditional statement(s) around it being false or it is being executed and is producing output, but you are not seeing it due to this combination of coding and php's stupid output buffering setting. if you want exact and direct help with what your code is doing, you will need to post all of it, so that we aren't guessing about what it may be doing.

are your form fields within a valid post method <form></form>? is your html valid? if it's not, the form fields could be broken and not be considered by the browser to be form fields. what exact post data is being submitted? 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 it detects? is the posted code the complete file? it's missing at least two closing } that would producing a php syntax error. lastly, in addition to the questionable statements and logic being used, to provide an audit-trail for the transactions, which also helps in debugging program operation, you should not just add/subtract amounts in a database table field. you should store each plus or minus transaction as a row in a table. to get the current total, you would just SUM() up the values for any user.

web servers and browsers are stateless. they don't know anything about any http request before or after the current one. when you refresh the page, it is requested again and it starts over and operates on any current data it is told to use. the $scope.comments array, that's hard-coded now, should instead be retrieved or dynamically built from the stored data on the server. by appending/pushing the submitted data to the $scope.comments array in the client, you have duplicated data on the client and on the server and can have the data out of synchronization if the server side code doesn't validate and store the data. data should only be stored in one place. next, this line - $json = file_put_contents('names.json', file_get_contents('php://input'), FILE_APPEND); isn't doing what you think. file_put_contents() returns an integer that's the number of bytes written to the file (or a false value if the file_put_contents() failed), so, while this will append the submitted data to names.json, the $json variable isn't either the submitted data or the entire contents of names.json. the reason you are getting php errors from the code is because $json, and then $data, isn't the submitted data. btw - don't use @ error suppressors in your code. they just hide problems, while still leaving your code nonfunctional. your task as a programmer is to find and fix problems, not hide them. this would be a good point to mention separation of concerns. i don't know from your program logic what you expect $json to hold, but if you separate the different concerns in your code, it would be clear to you and us what you are trying to do. saving data due to a form submission/post request is a separate concern from retrieving data to output it. your server side post method form processing code should detect that a post method form was submitted, input and validate the submitted data, then if there are no validation errors, use the submitted data. for what your application is doing, using the submitted data would mean to store it persistently on the server. you can display/dump the data for debugging purposes, but that is not the primary concern of the post method form processing code. if you then want to retrieve some or all of the the stored data and output it, this is a separate concern from the post method form processing and the code to do this should be a separate independent section in your file.

i would add to the above, those two database tables are required even in the case of a session based cart. at the point where the cart is finalized and converted to an order, you have to move the data from the session into the database tables so that you have a record of the order.

you need to decide if you are going to use a session or a database table for the cart. there are advantages and disadvantages to both, the main ones being - session based cart - 1) simpler sql queries - easier for someone just starting out 2) if the cart gets 'abandoned' it is deleted when the browser is closed database based cart - 1) requires more knowledge of sql queries, but uses overall less code and queries 2) if the cart gets 'abandoned' you must periodically clean up the entries in the database table. for a first time project, using a session to hold the cart will be the easiest to understand, design, and write code for. and once you simplify the data being stored in the cart (my item #2), the code to add/delete items in the cart is very simple. the code you have posted for payment.php is very badly written and either came directly or indirectly from code at w3schools. this code can be greatly simplified, just by using an array to hold the errors. it is a huge security risk to input and store credit card numbers on your site. if you are doing this for real, and you have a merchant account that you process credit cards through, they will have a list of security requirements you must meet for them to allow you to keep your account with them if you want to input and store credit card numbers. instead, you would transfer the visitor to the merchant's online payment gateway and the only place the credit card information would be input and used is on the merchant's site. the merchant's site would send your site payment confirmation information. no. this refers to the code with the - "SELECT MAX(paymentID) as paymentIDVal FROM usercheckout" query. actually, the PDO extension is simpler and more consistent then the mysqli extension. the reason for recommending that you store the user's id in the session variable is so the code is general purpose and any queries are slightly faster. you don't have to do this, but if you ever allow a user to change his username, you will have to also change the value in the session variable to avoid logging the user out. on any page that you want to display user information, you would query for it using the user_id, rather than the username that you are doing now. the most straight forward implementation would be to have two tables - 1) orders - order_id (auto-increment) - assigns an id to the order/cart user_id - the user's id date_time_created - the data/time the order/cart was created - also used when cleaning up abandoned carts. status - the order status. initially, the status value would indicate this is a pending order, i.e. just a cart with items in it. when the cart is converted to an actual order, the status would be updated with a value that indicates this. when the payment is verified, the status would be updated to again. other columns unique to each order 2) order_items - id (auto-increment) - assigns an id to the items in the order/cart order_id - from the orders table - identifies all the items that are part of the same order item_id - the item id from your product/item table (note: if you will have different types of items, they should all be in the same table with a category column.) quantity - quantity of the item status - status of the item (this would be things like back-ordered, shipped) when the visitor adds an item to the cart, if there isn't a record for the user's id with a status = cart in the orders table, a new one is inserted, the last insert id would be retrieved and stored in a session variable. this assigns an order_id for this cart. you would use this order_id when inserting rows in the order_items table. if you update the quantity or delete the item from the cart, you would runs queries on the order_items table.

your query is failing, because you are listing the wrong number of inputs in the type string for the bind_param() statement. this would either be throwing a (php?) error at the bind_param() statement or a mysql error at the execute() statement. you need to ALWAYS detect and handle statement errors. the easiest way of detecting and handling database statement errors is to use exceptions. to enable exceptions for the php msyqli extension, add the following two lines before you make the database connection - $driver = new mysqli_driver(); // note the $driver variable name used here is separate from and not related to any variable your code may be using $driver->report_mode = MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT; // MYSQLI_REPORT_ALL <-- w/index checking; w/o index checking --> MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT; then, php will catch the exception when there is an error and if you have php's error_reporting set to E_ALL and display_errors set to ON, php will display the actual cause of the error and some back-trace information.

from your statement, it's not entirely clear what sort of problem you need help with. however, in looking at the code, what you have now isn't going to work. you have a session based cart at one point and a database based cart at another. programming requires that you have a clear definition of what you are trying to accomplish and what the data is going to be, before you write any code. some overall suggestions - 1) any action that modifies data should use a post method form. your 'delete from cart' should use a post method form. 2) simplify your cart definition. if you use the item id as the cart's array index and the quantity as the value, all the code will be simplified. you should pass the minimum of information through a form, since you must validate all the submitted form data. the item name and price is known on the server. passing it through the form and storing it in the cart is just more work and more code you have to write and test. 3) if the cart is empty, you should output a message stating so. at the point where you are trying to display the cart or inputting the customer information during checkout, if the cart is empty, display a message stating so. don't leave the visitor guessing why the page isn't doing anything. 4) you have a <form></form> that you have put href/links into. that makes no sense, just output the navigation links. 5) aside from your payment.php code using a database based cart, which is not where the myorder.php code is storing the cart, this code looks like a w3schools copy/paste fail. all those variables you wrote out is not how to do this. you would use an array to hold the validation errors and also serve as the error flag. if the array is empty, there are no errors. if it's not empty, there are errors. 6) you should also not input or store the credit card number, even if this is just a programming class exercise. 7) you cannot (successfully) retrieve the MAX() column value from a database table and use it. multiple rows could have been inserted due to concurrent visitors and you can get the wrong value. to get the correct auto-increment id value following an INSERT query, use the last insert id property/method for the php database extension you are using. for the mysqli extension, it would be the mysqli::$insert_id property. this test_input() function is nonsense from the web. please DON'T copy code you find on the web. actually learn how to validate input data and safely supply it as input to sql query statements. to safely supply data as input to sql query statements, you should use a prepared query, which the php mysqli extension doesn't do very well. if you can, witch to use the php PDO extension. 9) since the visitor must be logged in to display the cart, your code should require the visitor to be logged in to add or delete items to/from the cart. the add to cart and delete from cart form processing code should only be executed if the visitor is logged in. i would store the user's id, not the user's first name, in the session variable to indicate who the visitor is.

here's a much easier way of doing this. get the main table's last insert id, like you are doing now, and as you loop over the uploaded files, for each successful one (your code isn't actually testing the ['error'] element to know if the file uploaded without any error), simply insert a new row containing the main table's last insert id into whatever $table3 is. get the last insert id from this table and use that as the destination file name for the move_uploaded_file() statement. this assigns a unique id (filename) for each image. if you are storing information about each image, such as original file name, description, ... you would store it in the correct row in this table. to 'edit' the file information, you need to handle each possibility - 1) no change, i.e. keep the existing image. you would display the existing file (thumbnail), original name, description, and use the image id (filename) as the type='file' form field name's array index value, which will become the $key value in the php code. i would use a different form field name for existing images (such as 'existing_files'), from the form field name for new images (currently it's 'files'). if no new file is uploaded (there's a specific error value, which is where checking the ['error'] element comes in), you would do nothing for the particular image. 2) replace an existing image. in this case you would select a new image in the browser and upload it. the ['error'] element would indicate a successful uploaded image. you would get the existing id (filename) from the $key value, and after making sure it corresponds to the current main table data being edited, you would simply use the id (filename) in the move_uploaded_file() statement to replace the image, leaving everything else as is. 3) delete an existing image. you would have a checkbox as you have theorized. the checkbox name would be an array with the array index value being the id (filename). for any checkboxes that are checked, you would get the array index value and after making sure it corresponds to the current main table data being edited, delete the corresponding image file and the row in $table3. 4) add image(s). this would use your existing code. by using a different form field name for existing files and for new files, the 'edit' code and the 'insert' code would operate on their own set of form fields. this will simplify your existing database code, making it easier to update it to current best practices and standards.

the primary id column should be an auto-increment integer. it should not be a character data type.

an auto-increment column needs to be an integer data type.

you can either add that term as an entry in the $and_terms array or create and use a 'view' on your database table.

there is a limit to the amount of data in one row. for what you have described, you would store each data item in its own row, with phone_id, config_id, and value columns. to retrieve the set of data for any phone, you would just query for the rows having that phone's id value. the phones and configuration names would be defined in other tables, giving the phone_id and config_id to use in the configuration storage table.

it would be helpful if you define what the work-flow (steps) is (are) before you try to write code. it will also help us if you tell us what the work-flow is supposed to be. something like - 1) connect to device, 2) retrieve user and attendance data, 3) display data in forms, 4) submit form, 5) store submitted data into database table. are you displaying the data as part of the learning/debugging process and you want to 'automatically' insert the data into the database tables OR are you trying to display the data in a form and you will manually submit the form to cause the data to be inserted into the database tables? next, you need to separate the different concerns in your code. any form processing code should be near the top of your file and come before you output any html to the page. the form processing code would come before the <!DOCTYPE tag. all the form processing code would be grouped together. to display the page, your code is retrieving user and attendance data from the time-clock. the code to retrieve this data and store it in php variables should be grouped together and come before you start outputting the html document. you would then simply loop over this data when you output the html document. if you are outputting the data in a form, perhaps to allow it to be verified and edited by a manager, you would need to output it using form fields, in a valid form. there are currently no <form...> tag(s) and no data-input form fields in your code. your attendance data output doesn't even have a <table> tag, no <tr></tr> <td></td> tags and no echo statements for the data.

you would produce the correct ALTER TABLE or CREATE TABLE query and execute it, provided that you can even create a database user on your hosting that has permission to alter/create a database table. however, everything you are asking points to a bad design. you shouldn't be dynamically creating tables/adding columns. 400 fields/columns in one table would be highly unusual and in it self indicates the data isn't being properly normalized (databases are not spreadsheets and trying to use them as one results in a lot of complicated code and queries to accomplish even simple tasks.) care to share some relevant information about what you are doing and a sample of the columns/fields you intend to dynamically add to a table?