No, the example I gave earlier uses your existing <option> values.
I was simply using the 'call_type' variable directly in the page because the value of the variable was the same as the filename for the page:
http://www.example.com/path/to/incoming.php. If it's not always so, then you couldn't do it this way; but if it is, then it saves some coding.
The other block of code I showed you was basically doing the same thing. The
only difference was how we validated the
call_type.
without the database, we defined the valid values in an array used
in_array() to make sure that the
call_type was correct.
with a database, we list the valid values in the database and use a query to see if
call_type was an allowed value.
PHP Code:
if (isset($_POST['call_type'])) {
// escape the value
$call_type = mysql_real_escape_string($_POST['call_type']);
$result = mysql_query("SELECT `call_type` FROM `tbl_calltype` WHERE `call_type` = '{$call_type}' ");
// if there's one row in the result, then there was a match.
if(mysql_num_rows($result) === 1){
// send the header()
header("Location: http://www.example.com/path/to/".$call_type.".php");
}
}
I hope my suggestion didn't confuse things. I only offered the alternative because maintaining a database for only two values might be "overkill." but if there are other possible values, or if the info is used by other scripts as well, then using the database is definitely the way to go. even if it's not needed, it won't really hurt anything to use a database anyway.