If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

First - horrible coding. Once again - NEVER ACCEPT INPUT FROM THE CLIENT THAT IS NOT ESCAPED BEFORE YOU PUT IT INTO YOUR DATABASE. You are just BEGGING to be hacked.

That said -

Go look at your PHP reference manual/book/resource and read up on how to write an array reference. Or try to think like the PHP interpreter. If I'm the interpreter I'm looking at this:

$_POST[email_id]

and saying to myself:

ok - this guy wants a value from my $_POST array. Got it. But what is this email_id thingy? I don't know any PHP variable by that name. What to do with this thing? ok - I'll put out a warning message saying "I don't know what this index you've given me is". Which is exactly what PHP has done.

Well, the root cause of your specific problem is not having method="post" in your form tag. Even after fixing that, you should still use isset() or empty() to verify the $_POST values you need are actually there before you try to use them.

As alluded to above, though, there are issues with using unsanitized inputs directly in your SQL. At the very least, look into mysql_real_escape_string(). Better yet would be to use PDO or MySQLi extensions and make use of prepared statements with bound parameters.

the error you get is saying there is no value assigned to that variable. As said above.
If you encounter this error later on you might want to consider putting an @ in front of your $_POST['variable name'].
Doing this will prevent it from giving an error like this. (in the current situation you should really prevent your script from inserting empty rows)

the error you get is saying there is no value assigned to that variable. As said above.
If you encounter this error later on you might want to consider putting an @ in front of your $_POST['variable name'].
Doing this will prevent it from giving an error like this. (in the current situation you should really prevent your script from inserting empty rows)

I'm not a fan of using the "@" error suppression operator, as that's just sweeping your garbage under the rug instead of really getting rid of it (the garbage, not the rug). I prefer to develop with all error/warning/info messages enabled; then code, test, add defensive code, test some more, etc., until there are no errors/warnings.

With experience you learn the common places where such things happen, and start putting in that defensive coding from the beginning.

"Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
~ Terry Pratchett in Nation