mac_gyver

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.

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?

^^^ then you should have posted the original code that didn't have the include statement commented out. by posting adulterated code, you wasted everyone's time making off topic attempts at helping you. the help you get is only as good as the information you supply.

if you would post those exact errors w/line numbers, someone COULD help you with what's causing them, because the magic 8 ball we resort to using when someone doesn't think it's necessary to share specific information they have about a problem doesn't show us what you are seeing in front of you.. it's likely they are not exactly the same errors/line numbers as what you posted at the top of this thread.

what sort of error or problem are you having with this query? if you remove all the (), which don't appear to be doing anything, it looks like it should work.

this code is not good and it's not safe. afaik, the XMLHttpRequest() object is not universal between browsers. if you are going to use ajax, you must either take into account all the likely browsers or you need to use a library like jquery to do this for you. before you can ajax, you must be able to html. your form and your form processing code must work properly before you can add ajax to it. your page should also work of someone has javascript disabled. once you get your form and form processing code to work, adding ajax is as simple as adding an event listener tied to an id or class in the form tag, prevent the default form action, serialize the form data (which takes a single statement to operate on all the successful form fields), submit the data, and handle the response. next, because anyone or anything can submit data to your form processing code, it must enforce security. your form processing code needs to detect that a post method form has been submitted, validate the input data, safely produce the message body, and any email address you put into a mail header must be validated to insure it contains only one properly formatted email address to prevent mail header injection. lastly, emails being sent from a form submission on a web site are NOT being sent from the email address that someone entered in the form. the emails are being sent from the web hosting mail server or a third-party mail server. the From: email address must either be hosted at the sending mail server or there must be an SPF record at the domain in the From: email address that says the sending mail server is authorized to send email for that domain.

this error has probably been occurring for some time, but because your code/site isn't using the imagick extension, and you haven't had the php error_reporting/display_errors setting set to report all errors, it hasn't been shown. this error, while it should be fixed, isn't relevant to the immediate problem. if the form field names and values are showing up in the browser address bar, it's because the JavaScript isn't submitting the form and the browser is (the <form tag doesn't have a method attribute, so the default get method is being used.) if the code worked before, what exactly have you changed in it?

Nooooooooo...... this code is logically incorrect and if you are using this same basic code for the email version, it is not secure. the point of a captcha is to prevent non-human submissions from working or unnecessarily using server resources. the current code, if there is no captcha field in the submitted data sets $validQuery = true; and merrily runs the rest of the code. only if there is a captcha field in the submitted data and its value matches the expected value should the rest of the the form processing code run. you should not have any other statements before you have verified the captcha. your form processing code, regardless of what it finally does with the submitted form data, must first test if a post method form was submitted. next, only checkbox and radiobuttons in a form are 'optional' and may not exist in the submitted form data. by using an isset() test for a field that is 'required' makes that field 'optional'. if you need (that still hasn't been determined, since you should find and fix what's causing the slow email operation) to convert from sending an email to recording the submitted data, all you should do is take the same information you have now that's going into the email and (securely) insert that into the database table, along with recording the date/time of the submission, perhaps other things like the visitor's ip address..., and a status field, that would be used to control if the record has been send in the summery email. there's no need for all the rest of logic you have shown. all you are doing is changing what happens with the submitted form data. next, to implement the cron based sending of a summery email, you would just find the records in the table that have a status that says they have not been sent, retrieve the data, produce the summery email, and if sending is successful, change the status to indicate they have been sent. you could also have a field in the table that you update with the send date/time.

wouldn't that mean exactly what your comment in the code states - where is the 'id' in the URL coming from? wouldn't the edit link that you are producing on one page and code using a value from that link on another page need to use the same name for the GET parameter? after you get (pun not intended) the names to match, is there actually an id value in the link? and this is the problem with you just wanting the code to work and wanting someone else to tell you why it doesn't, you are not involved with, looking at, following, and getting what the relationship is between the different pieces of code in the process.

you would need to use php's output buffering statements.

that''s not what he stated. you are the only person here that can investigate what your code and your data are doing. in order to fix a problem, you must find what is causing it. otherwise, all you are doing is trying to make symptoms disappear, which will just mess up the code and leave the problem intact. in programming, except for very overt problems, there is not a 'one symptom' is always caused by exactly 'one thing' relationship, because there are multiple different methods of accomplishing any task. a dozen different people could have written a questionnaire application, that produces the same exact symptom you are getting, and the cause could be different in each application. the error and line of code you posted is only the tail-ass-end of the problem, it's a symptom. without knowing fully how your code got to that execution point and what processing it is doing on the data up to that point, we cannot even suggest what to do to narrow down the problem. had the code been written with validation and error checking/reporting logic in it, the code would be helping you by telling you the first point where something wasn't as expected, rather than continuing to execute and giving you a php error at the tail-end of the problem. fundamentally, if the code is well written, it will tell you when, where, and why it is failing. no one is suggesting rewriting all the code, but if it doesn't have useful validation and error checking/reporting logic in it now, it was never actually finished to begin with and still needs some work done on it. the only hints i can give are general purpose debugging - 1) do you have php's error_reporting set to E_ALL? you are likely getting related Notice errors earlier in the code that could help pin down the problem. you may in fact be getting an undefined index Notice error at the same line code you have posted. 2) is php's output_buffering turned OFF, so that messages your code echos and php error messages won't be hidden if the code is doing header() redirects. 3) because it's random, it's due to either a race (timing/request) condition, an initial (initialization) condition, or assumption that the code and data are making. beyond those, you have got an application that doesn't work. you would need to post enough of the code that reproduces the problem for us to even be able to give specific suggestions on what to check.

what debugging have you done to find out WHAT the code IS doing? 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? are you sure the elseif() statement being shown is true and that no prior related if() or elseif() statement was true so that the shown elseif() will even be executed? do you have the PDO error mode set to exceptions so that database errors will throw an exception, combined with the suggested php error_reporting/display_errors settings, so you will see any database errors? is there a header() redirect later in the code that could be redirecting back to the same page, combined with php's output_buffering being on, that would hide any php errors or any output from echo statements in your code?

yes, $type is one variable, it's an array variable. it has more than one dimension. each array index references a different element of the array variable. there is a posted example showing how to use the $type array, for one of the stated purposes, of replacing the switch/case statement. that example would be this code - $alertID = ''; $alertClass = ''; if(isset($type[$event])) { list($alertID,$alertClass) = $type[$event]; } i'm guessing you don't understand what that is doing? $type is the array that has been defined and has had four elements assigned to it. the 'Tornado Warning', 'Severe Thunderstorm Warning', 'Flash Flood Warning', and 'Flood Warning' are the array indexes. supplying a literal array index name - $type['Flash Flood Warning'] in some code would reference the id and class values that are stored/assigned for the flash flood warning array index value. supplying a variable array index name - $type[$event] (assuming that $event is a string, rather than an simplexmlelement object) in some code would use the value in $event as the array index and would reference the id and class values that are stored/assigned for whatever is in $event. using isset($type[$event]) is testing if the element in the array $type, given by the array index name in $event is set. using list($alertID,$alertClass) = $type[$event]; is referencing the element in the array $type, given by the array index name in $event, and assigning the id and class values that are stored for that array index name to the $alertID and $alertClass variables. note: once your code has parsed and filtered the xml data so that only data having those four types is being processed and displayed, there's no need for the if(...){...} conditional logic or initializing the $alertID and $alertClass to empty strings. the event types in the data being looped over will be in the $type array and you only need the - list($alertID,$alertClass) = $type[$event]; line of code.

don't know what that is referring to, since nothing posted is doing that. you can require the defining array and the couple of lines of logic anywhere you want. if you do the other things that are needed to accomplish the stated goals of only keeping data of those types and ordering the data in the output by those types, the defining array will need to be required before the point where it is first referenced. the errors you are getting, which you didn't post, but i'll guess anyway, are either due to this - $type = array($event);, which isn't what i posted, that's creating an array with $event as the value in it, or they are due to the fact that the various child values you are getting are SimpleXMLElement objects, not strings, and for the case of using $event as an array index, needs to be cast to a string either implicitly, by adding double-quotes around it where it is used, or explicitly by using (string) when the value is first assigned to $event.

to do this will require changing how your code works, by separating the different 'concerns'. you need to separate the parsing of the data from the display of the data. in the parsing code, you would store the data into an array of sub-arrays, using the event type as the main array index and only store the types that you went to keep. you would only store the raw data values, without any formatting. you can use print_r() or var_dump() to verify that the data you have stored is what you expect, before going onto the next step of producing the output. in the display code, you would loop over the main array indexes in the order that you want to display them. this will give you any sub-arrays of data for each event type. you would loop over the sub-array and produce the output from the data. all the formatting code would be in this section. lastly, i'm sure in one or more of your threads, it has been suggested (by me) to not write out php logic just to map one value to another. you should use a simple mapping array. see the following - // define a map of the event type string, to any other values. the two entries are the alertID and the alertClass // this defining array is also used in the parsing code to control what event types are kept - if $type[$event] isset(), keep the data // is it also used when displaying the data. the order of the entries here controls the output order, by looping over the keys (see array_keys() ) from this array to access the parsed data in the same order $type = array(); $type['Tornado Warning'] = array('Tornado', 'AlertTornado'); $type['Severe Thunderstorm Warning'] = array('SevereThunderstorm','AlertSevereThunderstorm'); $type['Flash Flood Warning'] = array('FlashFlood','AlertFlood'); $type['Flood Warning'] = array('FlashFlood','AlertFlood'); besides the uses listed in the comments, this converts your design into a general purpose 'data driven' design, where any specific data values are pulled out of the program logic, leaving the program logic simplified and general purpose, and by putting the data values all in one place, you eliminate repetition in the code and make it easy to add, remove, or alter any of the data values. edit: by switch'ing (coding pun intended) to a data driven design, all that switch/case logic can be replaced with this - $alertID = ''; $alertClass = ''; if(isset($type[$event])) { list($alertID,$alertClass) = $type[$event]; }

actually, naming form fields (variables, db column names, or anything else) with an incremental number is a bad design that takes more code to produce the markup and process the data. you should use an array name for the form fields. - name="School[]", name="Student[]", and name="Class[]". this will submit the data as a php array for those field names, that you can simply loop over and access the values from each set of form fields within the group.

^^^ i'll have to digest that before replying fully. direct (parent) items are the things that are specifically and intentionally picked by the sales engineer, i.e. quantity 3, steel man door, quantity 10, 3 x 5 sash window.... picking these results in a direct bom that consists mainly of the item id and its quantity, that's stored with respect to a project/building id. the indirect/derived/calculated (child) items are the incidental items, fasteners, sealants, lift rental, labor (i'm assuming you are handling time/labor using this same system) ... that are the result of each direct item. currently, any time you change something on the direct bom, your code is looping over all the possible indirect items (in a bottom up fashion, in your original thread some time ago, it was mentioned to use a top down method, so that only things that change get recalculated) and is using values and equations hard-coded in the logic (hopefully to be converted to this data-driven rules based method) to calculate the quantity of each indirect item id. this produces an indirect bom that mainly consists of the indirect item id and its quantity. entering new items, of either direct or indirect type, can be done en-mass without regard to any association. the page where you define new or edit existing rules could be with respect to either the direct item or the indirect item, and you may want to do both. what i described above is with respect to the direct item. for any selected direct item, you would be able to see what existing rules there are and can edit, delete, or add new indirect items. so, for something like a window, you would see and edit any fasteners, flashing, sealant, ... for an edit page with respect to the indirect items, such as white caulk, when you select that item, it would show you all the rules defined for it and what direct items it is used with and if you are using categories, like in an example earlier in this thread, you can either just list the category name(s) or retrieve and display all the actual direct items that are under any category based rule. this indirect item edit page may be more useful for reporting purposes, rather than being the primary method where you define/edit the rules. lastly, i'm assuming that you have the direct bom stored in a database table. once you have these rules stored in a database table, for at least the unit_rules, you can produce the indirect bom entirely in one sql query (join the bom table with the rules table using the direct item id, sum the - bom quantity times the multiplier plus the offset, and group by the indirect item id). you may be able to also apply the group_rules in the same query, but that's more thinking than i want to do on this subject.

the id in the $unit_rules[...] would be the item id of a direct item. since i don't know how you are entering/specifying what would trigger the scissor lift due to the building height, i suggested a general purpose way of having a "building height adder" item, which would be a direct item that a person can pick and add to the direct bom. if you already have an item that will always be present on a bom that does this, you would use it's id in the rule. not sure if i follow, but for at least the direct bom, these are items that are selected by a human. they should only be stored in the database bom table if they have been selected for a project/building. if you are initially inserting ALL available items into the bom table, this is creating more work, increasing data storage requirements, probably takes more code, and may be where some of your performance problems are at.

re: post #13. i would say the answer is yes. but you should work out how you are going to do this for each case. some example cases - 1) adding a new direct item that uses no indirect items - enter the information about the new direct item and save it, ignoring anything else that might be present on the page to support example cases #2 - #4. for example, an entry floor mat that will just be laid on the floor. 2) adding a new direct item that uses an existing indirect item - enter and save the new direct item information per example #1, but make use of a search/select interface on the page to choose from existing indirect items. for example, an entry floor mat that will use double-sided sticky tape to hold it in place. after entering and saving the new floor mat information, display any existing indirect items that reference the chosen direct item (there will be none since this direct item has just been inserted/created) and use the search/select interface to display existing tapes/adhesives (whatever you are using to categorize items.) and select (checkboxes or perhaps just by entering the unit multiplier/offset data) which indirect item(s) are to be used with this direct item. after entering any multiplier values, save the new rules for this indirect item to the existing rules that may already exist for it. 3) adding or editing indirect items for an existing direct item. same as the second part for example case #2. rather than entering and saving the information for a new direct item, just select an existing direct item. the edit page would display the direct item that has been selected, any existing indirect items that reference the chosen direct item (so you can edit the rules, including deleting rules) and the search/select interface to let you add more indirect items for the chosen direct item. 4) adding a new indirect item. near the search/select interface, if there isn't a suitable existing indirect item, have entry form fields to add a new indirect item, that once added can be selected for the current chosen direct item.

most of the time, when it appears like you have multiple sessions that change depending on the method used to reach a page, it's because the host-name/sub-domain (the www. in the address) is changing depending on how you reach the page. are the url's in the links and in the redirects constant and always have the www. as part of them? as to any other problems in the code, you have far too much logic, due to an overly complicated data design. if you use the product id as the cart's array index and only store the quantity as the value in the array element, all the logic to manipulate the cart contents will be simplified. for example, here is what the add to cart logic would look like - // if the cart doesn't exist, create an empty one - you should put this logic in a common location above any code that references the cart if(!isset($_SESSION['cart_array'])) { $_SESSION['cart_array'] = array(); } // add a new item to cart with quantity 1, if already in cart add 1 to the quantity if (isset($_POST['pid'])) { // pid is the product/item id $pid = (int)$_POST['pid']; // cast, or better yet validate, the value to php integer (will be limited to the operating system's maximum integer value) if(!isset($_SESSION['cart_array'][$pid])) { // if the item isn't in the cart, add it with quantity 0 (the quantity will be incremented to one in the next statement) $_SESSION['cart_array'][$pid] = 0; } // add 1 to the quantity $_SESSION['cart_array'][$pid]++; header("location: http://www._______.c...om/cart.php"); // you need to either set up a defined constant, a php variable, or use $_SERVER['HTTP_HOST'] to supply the hostname/domain for url's so that you don't need to type them in each instance throughout the code exit(); } all other code will be equally simplified. next, you should not run an sql query inside of a loop. to display the cart contents, just retrieve all the product id's (see array_keys() ), which will be either cast/validated as integers by your add to cart logic, form a comma separated list (see implode() ), and run one sql query with - WHERE id IN(the_comma_separated_list_goes_here) to get all the product data at one time. you can loop through the data from the query to display the cart, using the product id from each row to access the quantity value in the cart. lastly, the php mysql extension is obsolete and was removed from php almost one year ago. you need to be learning current information or updating your code to use either the php PDO or msyqli extension. the PDO extension is more consistent and simpler to use over the mysqli extension.

the data-driven rule based logic is only to replace the hard-coded logic you have now, for determining the derived quantity of dependent items, based on the primary/direct entered item. if you don't have any hard-coded logic calculating the quantity now, there would not be any rules needed. you probably don't have the item in your switch/case statement either. you have a direct bom, of the items that are selected by people and an indirect/derived bom, of items that this thread is trying to calculate. it's only the indirect/derived items that will have rules defined for them.