Clarding

Thanks mac_gyver, I hadn't spotted that! The file that set the error reporting occurred just after the database connection, so you are spot on with that. Moved the error reporting up a couple of lines, and the deprecation warning now comes up just as expected. Very many thanks.

I recently upgraded to 5.5.3 and I read that mysql_ functions are deprecated, which is great and I would like to ensure a warning is seen when mysql_ functions are used. So I set my error reporting ON and still any use of mysql_ functions does not result in a deprecation warning. Do I need to change something other than doing this: error_reporting(E_ALL); ini_set('display_errors', 1); Or, why does calling a mysql_ function not result in a deprecation warning? phpinfo() tells me I am on php 5.5.3

Yes, vinny42 is absolutely right - I stand corrected! Very well said Vinny42 and we can certainly learn from those wise comments.

You are safe from anyone executing rogue exe files on your server because all the exe files can do is offer the user to download them, and you're ok with that. Please also make sure that .com, .bat, .cmd etc also offer themselves for download - as long as the file is offered for download, then it cannot be executed on your server by a web browsing user. However, I'd prefer (and this is what I do on my site) is to permit zip files and insist that all exes etc are zipped up first (by filtering the file type at the point of upload).

>>"...you should sanitize the values..." Sorry, but no, please don't rely on sanitizing values - it's not reliable to do that, everyone really ought to use parameterized queries - the sooner you get into the habit of using parameterized queries the better, then they'll become second nature to you. Where I completely agree with Josh is that it would be better to use checkboxes, certainly.

There's a couple of approaches you can take here, for example your BOTH value could be Pete' OR driver='Julia Please note how the single quotes are arranged rather oddly, so that it makes sense once the sql clause is constructed. But please please don't do that! your code allows SQL injection and that's not something anyone should allow - too many commercial sites are prone to sql injection and we all need to make sure we never allow that to happen in our code. So, I have to say (and will probably say this over and over again in this forum!) that you should never take the submission from the form and use it directly in your SQL string. Instead, use parameterised queries. Using non-parameterised queries (i.e. joining together strings that use form-submitted values to construct a SQL phrase) is a big no-no for security reasons (sql injection). Instead, you would store the values posted by your form in the SQL parameter variables, and the first two possibilities (i.e. just Julia or just Pete) will simply be WHERE `driver` = ? and then the parameter that you pass to your SQL will occupy the ? slot without having any worries about SQL injection. (by the way, this also allows for names such as O'Connor without worrying about apostrophes that would otherwise break your code - parameterised queries really are the way to do ALL sql processing). Anyway that leads us to the third possibility, i.e. "either name". To answer that, have your HTML value equal to "BOTH" and then in your php code say something like if ($driver === "BOTH") and construct your (parameterised) sql accordingly, i.e. with a sql statement that says WHERE Driver IN (?,?) and pass the sql statement two parameters, one for each name you are looking for. So having got this far, I then have to say the previous advice can be improved upon because it is too deeply coupled to the form, that is to say your backend code relies on the form having just two names and the "BOTH" option, so you'd then want to add refinement to your handling of the form submission so that "BOTH" is actually much more flexible, in case you later added a third or fourth name. So instead of having "BOTH" in the value for the form field, have perhaps "Pete,Julia" as the value for the form field, and then get your php script to explode that on the comma delimeter, and you end up with a nice array of people's names. I find myself building parameterised SQL phrases by putting as many question marks in the sql string as there are elements of the array, and passing the array of values as the sql parameters. That way, you can have as many names as your form submits in the "Both" field, although with three or more names it'll be an "Any" field. What you really need to aim for is to totally decouple the form and the backend php code, so that the php code can handle any number of options on the form. I hope that explains things.