scootstah

You are not checking for a POST request, so you are just going to be inserting empty rows every time you load the page. The $_POST superglobal is only going to be populated when you send a POST request. So do something like; if (!empty($_POST)) { $insert_query = "INSERT INTO Car (Make,Model,Price) VALUES (?,?,?)"; $Make = $_POST['Make']; $Model = $_POST['Model']; $Price = $_POST['Price']; $params = array("$Make","$Model", "$Price" ); $result = sqlsrv_query($conn,$insert_query,$params); $describeQuery="select Make,Model,Price from Cars"; $results = sqlsrv_query($conn, $describeQuery); }

Storing the credentials in a PHP file is usually perfectly fine. An attacker would have to gain entry to your filesystem to retrieve the database credentials. The only thing they can do with the database credentials is access your database, right? So even if you encrypt them, if an attacker has access to the filesystem he can just upload his own script and tap into your existing connection anyway; thereby having all the access to the database that he wants. EDIT: So put simply, if an attacker gains access to your filesystem you are screwed either way.

Post the code for more_fields() please.

Post code please.

I put all my brackets on the next line except for if/else/else-if.

After you run the query, do something like if (sqlsrv_errors() !== null) { print_r(sqlsrv_errors()); }

Do a header redirect after you have processed everything.

I think it's because you need a space before FROM. $describeQuery = "SELECT ID AS prod_id, Name, (SELECT COUNT(*) FROM MonthlySales WHERE ProductCode=prod_id AND Year = 1990) AS num_sales FROM Products";

1. The same way as any other form element. $_POST['gender'] 2. thorpe beat me to it. EDIT: Although, he forgot echo's. <label for="gender">Gender:</label> <select id="gender" name="gender"> <option value="">--</option> <option value="F"<?php echo (isset($gender) && $gender == "F") ? 'selected="selected"' : ''; ?>>Female</option> <option value="M"<?php echo (isset($gender) && $gender == "M") ? 'selected="selected"' : ''; ?>>Male</option> </select>

It's usually good practice to define the base URL somewhere, to ensure that it is always the way it should be.

For PHP, you can get Zend Certified.

Post relevant code please.

$str = 'A blagh blah blah blah blah. http://blah.com'; $str = preg_replace('/http:\/\/.*?$/i', '', $str); // $str = "A blagh blah blah blah blah. "

What does echo mysql_num_rows($result); give you?

I think it would be better to only have one user table and then have a group table which decides if the user is gold or silver.

var titanic:ship; jack,rose:human; begin jack.inlove:=false; rose.inlove:=false; while jack.inlove=false do begin delay(5000000); jack.interact(rose); end; jack.alive:=false; end. Haha, that's pretty funny.

Additionally, you can just check if $_POST is not empty and assume the request came from your form. You should be double-checking that relevant or necessary data exists and is in the format you expect anyway.

So uhh, I was looking at this new laptop...

You'll need to escape your data first. mysql_real_escape_string

Yeah, that's probably a better idea.

Right.. Carry on.. I'm off to the pub. My apologies, apparently I skipped over that.

While I would normally agree, I think manipulating $_POST in this case is acceptable. The reason is that 1) you probably won't need to preserve white-space at the beginning/end of the data anywhere else and 2) it ensures that if you re-display the form with prepopulated fields that they will be in fact empty, and not full of spaces (which might confuse someone).

Your question is pretty similar to this one which has a good answer here, so I won't bother repeating what he said. However I have some ideas for your other problems. For forwarding, you could simply create a new message that quoted the previous one, and add "FW:" to the subject or something. You don't need to have a special flag this way, and it keeps everything simple. As far as bcc you could just create multiple messages with different recipient ID's.

That's not the point. The point is that in the event her database was hacked, she doesn't want the hackers to be able to read the private message conversations. This has little to nothing to do with "who can see the DB".

base64 is usually pretty recognizable. It is absolutely trivial to decode it; I have a Firefox addon to do it in about 2 key presses. base64 was not made to be secure, so it is stupid to use it in such a way.