Muddy_Funster

I would change the tables slightly and have a "rating" type column for storage. i.e. bodyType | maxPassengers | maxStorage so your saloon would have 4 max passengers and a maxStorage of 5, your estate would have 4 max passengers and a max storage of 9 and so on. Then have a small bag worth 1 storage and a large bag worth 2. Then you can easily add up the form input and apply to the query: ... $storage = (int)$small_storage + 2 * (int)$large_storage; $qry = "SELECT DISTINCT bodyType, maxPassengers, maxStorage FROM vehicles WHERE maxPassengers >= $passengers AND maxStorage >= $storage ORDER BY maxPassengers, maxStorage DESC"; ... EDIT: @Barand said it better than I did while I was typing. *tips hat*

It's pretty much the every day use of PHP these days. also, here's a fiddle that emulates the behavior you are describing using a mock data set to prove your co worker is a muppet https://jsfiddle.net/7b4u37k7/1/

try: $.ajax({ url: ajaxUrl, type: "get", success:function loadDiv( response ) { $( "#MiddleColumnWrapper" ) .html( response ); } }

It's also arguably much more likely that the OP's making incorrect assumptions about how zero-fill works. I was simply choosing to respond to the info that was presented, nothing more.

I'm inclined to think, as @cyberRobot does, that it is something outside MySQL. The (11) is the display size, not the field length - so the value will be stored in it's entirety regardless. that you are only able to store 9 digits of a 10 digit "word" in an 11 digit display field points to it being a different issue. if it was dropping down from 11 to 10 I would suggest that it could be that the signed bit was replacing the least significant bit in the word and as you never have a negative phone number you never see the minus sign showing in that space. But that's not the case, so I expect there is something else at play.

either your root account has a password and phpmyadmin holds it in it's settings, or your phpmyadmin isn't using the root account. either way you shouldn't be using the root acount. you should have set up an account for normal use either with or without a password. root should only be used for initial config and for emergencies - neither of which covers this. Create an account yourself and try using that.

contents of the $last_played_by[] array? (particularly the keys of said array) also, seeing your classes set method would be something of an advantage.

when rendering your second table, you have the following: <input type="hidden" id="id" value="<?php echo $row['id']; ?>"> which will give every row the same id of "id". however, even if you appended the $id value you would then end up with each table containing an element with the same id for each row. you need to append your $id value to the input and also prefix each id input in each table and call that with the button.

Yeah, just me then :-D I didn't realise that PDO could use implicit binding on named placeholders. Example #5 on the manual page is more along the strategy I would take.

That's too little information. Is it only the second column (username) that is not being updated? does the ajax call fail or succeed? what debugging have you done so far? does the form contain the element id's that it should? The more (relevant) info you give the better we all can help

@maxxd That's going back to running the db transactions within in a loop... Something I personally disagree with. Also, it could just be me, but it looks like you're not binding the parameters for the prepared statement?

you don't use brackets for SET values: UPDATE `ctryvisits15`SET `Qtr`= 1 WHERE ẀNo`< 14

cyberRobot is of course correct. INSERT creates a completely new record, thus WHERE can not be used (there is no existing point of reference for a new record to use in this way). WHERE can only be used when interacting with existing data (using SELECT, or the suggested UPDATE for example). It is used to make conditions which reference the existing records in the table so that only the desired records are affected. If you give us a bit more background on what you are doing we can advise further.

It should look something like the following quick sample, although you should apply some validation on each $value and to $_POST['user_id'] before appending it to the query string: foreach($_POST['multiBox'] as $record=>$value){ (!isset($values)) ? $values = "({$_POST['user_id']}, {$value})" : $values .= ", ({$_POST['user_id']}, {$value})"; } $qry = "INSERT INTO user_competency (user_id, comp_id) VALUES ".$values; //example using PDO: $con = new PDO("mysql:host=<yourServerAddress>;dbname=<nameOfDB>","<DBuserName>","<DBpassword>"); $affectedRows = $con->exec($qry); ($affectedRows === 0) ? echo "Either there was nothing to insert, or something went wrong!" : echo "Success! {$affectedRows} were added to the database.";

first - STOP running queries inside loops - it's bad practice, resource intensive (comparatively speaking) and in some environments it will get your script blocked as a security risk. second - as was previously suggested: STOP writing new code using mysql_<xxx> it's out of date and will be removed very soon. third - be attentive with your operators : a single = sign is an assignment operator (that which is on the left becomes that which is on the right) and == is a comparison operator (is that which is on the left equal to that which is on the right) mixing these up will make your loops and other code misbehave....

well at a glance, you have given your table two different id's and you have not put any value parameters in any of your option elements, you have not assigned a name parameter to your last select element and you are only collecting member id's in your abc[] array element, not the data you have been previously stating. Here's a debugging tip : add the following line at the very top of update3.php (but still after the <?php tag) die(var_dump($_POST)); then fill out your form as you would expect it to be used and submit it. Post up what you get back from the update3.php page.

As long as you're only using them for a sort of "Concept realization" type goal, the "for dummies" books are pretty decent as far as language and explanations go. However, you should always, always refer back to the PHP manual site to make sure that what you code is up to date with current language practices., as QuickOldCar said, most print resources are out of date, not necessarily with regards to the big things, but there are a lot of subtle changes that happen in a fairly fluid way with PHP, as happens to a greater or lesser degree with all open source projects. One tip I would like to include for those starting out is to give phpfiddle a shot, it lets you code and execute script directly from your browser, without having to worry about having a development environment set up.

what exactly do you want to do? an array of objects isn't the same as an array of arrays. //example using forech: foreach($array as $key=>$object){ echo $object->id; } //example using direct pointer $object = $array[0]; echo $object->id;

it's been a long time since I created any custom mail, but I did post up my old script for creating a multi-part MIME mail using the PEAR Net_SMTP. Looking through that I remember that there are some nuances to getting each part of the message to work, including adding a content-type into the message as well as the header. you'll find my code :here: looking over how the message was constructed could give you some insight into getting the html to work.

I can see this has the potential to hijack the thread, so I'll just agree to disagree on this.

Well, the second example on the manual page (here) covers multiple additional headers...

True, but why would you want to do that in the first place? let's be honest it's of no real world benefit whatsoever. I hold that once a hash is stored in a table it should be left there, only used internally within the database for comparison and never returned as the result of a query. Again, it's a personal point of view, and I noted that already as I appreciate that a lot of people are quite happy throwing password strings all over the place. I also provided an alternative query statement and basic explanation of the process that would be more in line with how I would do it. However, as you correctly stated, I neglected to specifically point out that those functions would become redundant.

I strongly disagree with ever pulling passwords from database tables (Note: this is a personal opinion). I suggest that you would have a basic user table, conaining :||userID (Primary Key) | userName (Unique Index) | userPassword (Normal Index) | accountStatus (Normal Index) || From this you would simply select userID from the table, not the password. So your SQL would look like: SELECT userID FROM userTable WHERE userName = :user AND userPassword = :pwd AND accountStatus = "Active" Use PDO->prepare to create the statement and then statement->bindParam to attach the form values to the query string :user and :pwd parameters. You can then grab the userID for use in persistence and you can throw out a "Login failed" message in the event the query returns 0 rows.

first up, check that your global $current_user has something in it by var_dump() ing it , next, tell us what's happening in the get_currentuserinfo() function that you call in there. Then we can see what's going on.

Your SQL is incomplete Where id what?