mac_gyver

a UNION query built from the x number of SELECT queries would result in the fewest round-trip communications/queries ran.

no. that looks the same for the empty test. your current logic only reports that at least one of the required fields was left empty. not which one(s). your code also prevents the rest of the validation tests from running if there are any empty fields. there could be problems with the non-empty fields, but the user won't see those errors until they fill in the empty fields. this will result in an unhappy user, because he may have to submit the form extra times, when he could have corrected all the errors at once.

that's not what testing if $_POST is empty or not does. testing if $_POST is empty or not detects if the form was submitted. it's testing if any of the named form fields are present, even if they are empty, in the $_POST array. $_POST will be empty if no form was submitted or a form was submitted and the total size of the form data exceed the max_post_size setting.

this bit of code has several problems - if (empty($_POST) === false) { $required_fields = array('usernamne', 'password', 'password_again', 'first_name', 'active', 'email'); foreach ($_POST as $key => $value) { if (empty($value) && in_array($key, $required_fields) === true) { $errors[] = 'Fields marked with * are mandatory'; break 1; } } 1) you should not blindly loop through the $_POST data. a hacker can submit 100's or 1000's of values. you should instead loop through the definition of your fields and test the corresponding $_POST data. also, unchecked checkboxes and unselected radio button groups are not set in the $_POST data, so your current logic won't detect if a required checkbox/radio button choice hasn't be selected. 2) a zero is considered to be empty(), which is probably why your zero case wasn't working. 3) by breaking out of the loop upon the first empty value, you are only reporting a general error. you should specifically produce an error for each required field that was empty. this will help the visitor know what he left empty (yes, they need to be specifically told), and it will help with programming errors/typo's by reporting exactly which fields the code thinks was left empty. 4) this programming style is a killer - empty($_POST) === false. the empty() function is designed to return a boolean value that you directly use in your program logic. by adding another comparison operator to it, you are building up a forest of unnecessary code.

the error means an array element is being referenced that doesn't exist. adding isset() to test if something exists before trying to referenced it is only valid if what is being referenced is optional, i.e. it may or may not be present. this would be the case when testing if a page got requested and a form may or may not have been submitted, a form element may or may not exist (checkboxes, radio buttons), a get parameter in the url may or may not be present, or code didn't find any matching row in a database table and the code didn't take the added step of preventing any follow on code that's dependent on that data from running. for data that the code requires to be present, you would not use isset() to prevent the error. you would find out why the expected data isn't present by tracing back in the code to find out where it is being produced at and find out why it isn't being produced. adding isset() in this case would just be hiding problems. for the missing $product['key'], i would expect that the key element is required for this code to work at all. if some of the other $product[...] elements are present, but not the ['key'], you would need to find out why. one possible cause would be a difference in the index name from where the value is being produced and where it is being used. it might be ['id'] or ['product_id'] rather than ['key']. for the missing $product['recurring'], that one sounds like it could be optional. but it depends on where and how it is being stored/produced to determine if using isset() to test if it exists before referencing it would be appropriate. if the line of code for it in what you posted is the way the original code is, it would be a safe guess that it is missing an isset() around the $product['recurring'] in that line. sadly, problems like this in code you find posted on the web are due to the person writing the code not really knowing the reason behind what they are doing and are developing code with php's error reporting not fully turned on and/or not fully testing the code they have posted.

here's a thread/post showing how you would run an UPDATE query to toggle a value and retrieve a value from that row at the same time - http://forums.phpfreaks.com/topic/296803-get-id-after-update/?hl=%2Blast_insert_id&do=findComment&comment=1513845 the user_id in that thread would instead be your column holding the previously randomized numbers.

your stated method actually has a race condition where multiple concurrent instances could produce and try to insert the same number. you can do this using one INSERT query, which avoids the race condition. see the following example - http://forums.phpfreaks.com/topic/297377-going-from-sessions-only-to-remember-me/?do=findComment&comment=1517023 by only running one query, your code should be at least twice as efficient. i would think that 45 seconds for 1000 requests probably means that your current code has some additional inefficients and/or your database table doesn't have an index (the method in the code i linked to above requires an index.) does what you are using these values for require a random number or could it be an incrementing number? also, how many total numbers will there be, because another way of doing this would be to generate all the possible numbers, randomize them, then store them in a database table. you can just query for the next unused value. to avoid the race condition, you would actually run an UPDATE query to toggle a 'used' bit in an available row. then, if the UPDATE query was successful, you know that the row you just toggled contains your random number. you can get the number from that row by using the msyql LAST_INSERT_ID(expr) function in the query, then retrieve the number by fetching the last inserted id value.

this is the first prepared query in your code - $stmt = $DB_con->prepare(" ... "); this is the second one, where the error is at - $stmt->$DB_con->prepare($query); look at what is different in those, right after the $stmt variable.

it will be easiest if you add rows. if you weren't using a <table> for your layout, this would be simple. you could just define a template section around the first instance of a row, then dynamically append new instances - <script type="text/javascript"> function dyn_add() { // create an empty div element var div1 = document.createElement('div'); // get the template html and put it into the empty div div1.innerHTML = document.getElementById('template').innerHTML; // append the new div to the target area on the page document.getElementById('add_here').appendChild(div1); } </script> <p> <a href="javascript:dyn_add()">Dynamically Add another of whatever is defined in the template div</a> </p> <form method='post' action='formaction.php'> <!-- Template. This first instance of "whatever" will be appended in the add_here div --> <div id="template"> <?php // produce the first row/instance $fields = array('Quantity 1','Pressure','Vacuum','Quantity 4','Temp','Solids'); $temp = ""; foreach($fields as $element){ $temp .= "<input name='{$element}[]' size='3' type='text'>"; } $temp .= "<br>"; echo $temp; // output the first instance in the template div ?> </div> <!-- if you want to have more initial fields shown, output them here, after the template --> <?php echo str_repeat($temp, 3); ?> <!-- container to hold the dynamically added instances of "whatever" --> <div id="add_here"> </div> <input type='submit'> </form> however, this won't work with a <table> as you cannot put a <div> directly into a table. afaik, with a table, to append rows or columns, you would need to specifically build rows and cells where you want them and then append whatever html you want into each new cell. if you search the web for "javascript dynamically add table rows" you will find a ton examples. you could of course do this server-side using php to add any requested rows/columns to the html.

if you stored procedure worked when you were using mysql_ statements, the problem isn't in the stored procedure. i'm betting that nothing is displayed when you request your page. there's a space in the $my _p variable in the bind_param(....) statement that is causing a fatal php syntax error. when developing and debugging code, you must have php's error_reporting set to E_ALL and display_errors set to ON in your php.ini on your development system so that all php detected errors will be reported and displayed (parse errors in your main file won't be reported if you try to set the error_reporting/display_errors settings in your code because your main code never runs to cause the settings to take effect.)

to use a prepared query inside of a loop, the only things that go inside of the loop are the statements that populate the bound variables with data and the ->execute() statement. the code building the sql query, the ->prepare(), and the ->bind_param() should only exist once and come before the start of your loops. where is $l_planid defined at? should it instead be $l_pla? what symptom or error are you getting that leads you to believe that it is failing?

the error is self explanatory, it means that you are referencing an array index that doesn't exist. since the only reference to an array index by that name is in this line - $er_id = $row1["er_id"];, does your database table have a column named er_id? also, why do you have two database tables, one for employees and one for employers, and double the amount of code? that's not how to program. the visitors that are logging in shouldn't need to pick which type they are on the form page. all they should need to do is enter their email and password. it should be up to your single database table and your code to know what type they are. by having two tables, you are have to write, test, and debug double the amount of code for the form and for the form processing. lastly, the mysql_ database functions are obsolete and will be removed from php in the near future. you should be learning to use either the PDO or mysqli_ database functions so that what you are learning isn't already out of date.

that may be, but is the php language engine 32 or 64 bit? that statement concerns the form fields, not the <form tag. that sounds like it's one of the third-party flash based file unloaders. care to share which one in case someone has some specific knowledge about it and your symptom that could lead to a solution?

a post method form that has no name='....' attributes in the fields or has only empty name='' attributes in the fields will also send a CONTENT_LENGTH of zero. is there any chance that you are dynamically producing the form, either via php or javascript, or are using javascript to submit the form?

the methods we have shown in this thread are for the type of query you posted at the start of this thread, that is testing if there is a user row matching the id and to fetch that row if there is, i.e. a query that will match at most one row. if you are running a query that can return any number of matching rows, you need to write the code differently. you would need to test the number of rows, then loop over the result set if there are rows. as an alternative, since you should be separating your database dependent code from any html markup, would be to simply fetch all the rows, even if there are none, into a php array. then use that array any place you need to access the data. you can find how many rows the query matched by using count() on the array. you can loop over the array using a foreach loop to process the rows.

you must be specific, by showing what data you expected, what data you got, and what the actual code is that you are using.

normally, the Content-Length is the value that the browser sent in the request when it starts to submit the form data, even if that value is greater than the post_max_size setting. i'm guessing that you either found a bug in php or you are on a 32bit system, the post_max_size setting is greater than a 32bit signed integer (2,147,483,647), and the math that php is doing to check the Content-Length against that setting is failing and resulting the a zero being listed for the Content-Length. the fact that the limit is being reported as a negative number supports the 32bit signed integer limit possibility. also, afaik, when the Content-Length is greater then the post_max_size setting, php tries (wishful thinking) to abort the upload. it may be that the browser/client you are using respects this, and then sends another post request with a Content-Length of zero. what is your post_max_size setting (what exactly are you setting it to and what does a phpinfo() statement report it being) and are you doing this on a 32bit php installation?

when you successfully prepare a query, you get a mysqli statement object. you can only use the properties and methods that are part of a mysqli statement object. see this link for the documentation for those properties and methods - http://php.net/manual/en/class.mysqli-stmt.php you would need to use the ->num_rows property. you will also need to call the ->store_result() method before you can call the ->num_rows property (all the extra logic needed when using mysqli prepared statements is yet another good reason to use PDO instead.) since your query will/should at most match only one row, it will be more efficient if you just attempt to fetch the row. the ->fetch() method will return a true value if the query matched a row.

lol, you did a var_dump() on the values and looked at them, but didn't think it would be helpful to show us what they were? i'm going to venture a guess, the $id is probably a zero, which is considered to be an empty() value. if so, you should not be using a zero as an id (identifier), especially since the column in your database table defining the ids should be an auto-increment integer column, which won't normally start at zero.

no you don't. the html you posted at the top of this thread is a mess. it has two nested opening <form ...> tags and aside from the hidden form field, the form fields don't have name='....' attributes. you did give a name attribute to a <td ...> element that looks like it belongs in the submit button and there is no closing </form> tag. to do this thing called programing, you must first learn the basics. if you don't know the correct syntax for a <form ....> ... </form> at all, you will never get a form to work for your data. unless you can get one form field to submit to your php code, there's no point in writing out the html for more than one form field (and i as stated, you should let the computer write out multiple same meaning form fields.) you need to read a book, or take a class, or study up-to-date tutorials in order to learn the basics of writing forms and writing php code to process those forms, because you cannot do this just by throwing things together that you may have seen somewhere.

some tips - 1) you would dynamically produce the form, rather than writing out all that repetitive markup. you would either allow the user to enter (an input box) or select (a select/option dropdown) the number of fields to produce or you would display a base number of fields and have an 'add' button that would dynamically add more fields. 2) form fields need a name='...' attribute to cause the data to be submitted. for sets of data, you would use an array for the name so that you can process the data using php's array functions. see this link for using an array for form fields - http://php.net/manual/en/faq.html.php#faq.html.arrays 3) if the names of the cards are specific (i.e. the user cannot make up card names), you would want to provide a way of letting the user select from the existing card names. by requiring the user to type in a card name you will have all kinds of problems with misspelling and making it too hard for the user to enter data. 4) to display the card names for selection, you would either display all them at once, ordered by category and/or name, or if you have a large number of card names, provide a search box, category selection menu/links, or use pagination to limit what's being displayed at one time. in short, define your user entry form so that it easy for the user to pick/enter the data, give the form fields array name's so that the data will be submitted at all and it will be submitted as arrays of data, then it will be easy for you to write the php code that processes the submitted data.

not only that, all the radio buttons in the same group must have the same name so that the browser will cause them to operate as a group of radio buttons. giving each one a different name makes them completely separate radio buttons. in one of your previous threads, i suggested storing the price values separately (something you had asked about doing in an even earlier design based question), so that when you retrieve the product/price information, you could just loop to produce a radio button for each stored price. and in that earlier design thread both Barand and i (mostly him) gave you detailed help about how your data should be organized. a good data design, results in less code and less work for you, not more code and work. if you had stored the pricing based on the user type, you wouldn't even need these radio buttons. based on what you are trying to output, all you should need to do is write a JOINed query for the products you want to display and the price for those products based on the 'type' of the selected user, loop over the rows that the query matches, display the product name, display that user's price for the product, and output a form input for entering the quantity for each product. instead you have threads using select/option menus that contain one value to display the product name, hard-coded logic to display a radio button for each non-null price, questions about dynamically adding form fields and using javascript/ajax. you are making this harder than it is.

it shouldn't even be that. just echo the product name next to the radio buttons it belongs to.

finally, some information from you that helps, that you should have supplied in the first post in this thread. 1) that IS an error message. it's being produced in your code when the visibleMenu() method returns a false value (unless you have have that same error message in other places in your code and it's actually coming from somewhere else and not the call to the visibleMenu() method.) 2) the visibleMenu() method will return a false value when - if( empty($id) ) return false ; if ($visibol > 1) return false ; 3) since, $visibol is being set by your code to either a 0 or a 1 right before calling the visibleMenu() method, that means that $id is probably empty. 4) $id is coming from - $action = (isset($_GET['action'])) ? $_GET['action'] : null; $id = (isset($_GET['id'])) ? $_GET['id'] : null; $controllerAdmin = new controller_admin($action, $id); this means that there is probably no $_GET['id'] in the url. there is apparently a $_GET['action'], otherwise the code where the errore nel cambio dello stato is at wouldn't be running. 5) this is the code producing the url - if ($risultato['menu_visibol'] == 1) { $action = "?menu&action=novisibol"; $text = "novisibol"; $class = "novisibol"; } else { $action = "?menu&action=visibol"; $text = "visibol"; $class = "visibol"; } and this - <td><a title="<?php echo $text ;?>" class="<?php echo $class ; ?>" href="<?php echo $action . '&id='.$risultato['menu_id']; ?>"><?php echo $text ;?></a> </td> so, do the links on your page have an &id=some_value in them and that same part of the url is present in the address bar of your browser on the page where you get the errore nel cambio dello stato message (in case you have some url rewriting that's not carrying over that value)?

you are likely running up against a relaying restriction on your mail server, due to the neither of the TO: or FROM: address being hosted at the sending mail server. i'm betting that for the case where it sends the email, the TO: address is hosted at the sending mail server and for the case where it doesn't send, the TO: address is not hosted at the sending mail server? if you turn on php's full error_reporting/display_errors settings, you will likely be getting an error that points to the problem. the email is NOT BEING SENT FROM the person who entries their email address in your form. the email is being sent FROM your sending mail server (even if you are sending it to an address at that same mail server.) the From: email address must be an address hosted at your sending mail server or you need appropriate DNS records at the domain being put into the From: email address that says that your sending mail server is authorized to send email for that domain. only the REPLY-TO: address should be the email that was entered in your form.