2) Instead of worrying about quotes, you should use placeholders in the DBI statement, such as:

  $SQL = "INSERT INTO EMPLOYEE (
              EMPLOYEE_NUMBER, FIRST_NAME, LAST_NAME, INFORMATION_DATE
+)
              VALUES (?, ?, ?, SYSDATE)"
+;
  $sth = $dbh->prepare($SQL);
  $sth->execute( $employee_number, $first_name, $last_name );
[download]

Finally, not asked, but you're checking for errors in a very odd way. DBI statements don't die, so using eval won't catch errors. Instead, you should check the error status via the $DBI::errstr variable, and do this after every "prepare" and "execute" statement, such as

  $SQL = "INSERT INTO EMPLOYEE (
              EMPLOYEE_NUMBER, FIRST_NAME, LAST_NAME, INFORMATION_DATE
+)
              VALUES (?, ?, ?, SYSDATE)"
+;
  $sth = $dbh->prepare($SQL) or die $DBI::errstr;
  $sth->execute( $employee_number, $first_name, $last_name ) or die $D
+BI::errstr;
[download]

  if ( !$sth->execute( $employee_number, $first_name, $last_name ) ) {
    print "Could not insert into database: ", $DBI::errstr, "\n";
    return;
  }
[download]

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important

++ on the placeholder issue (it's the only way to fly), but since the original code had RaiseError => 1 in the connect(), every DBI call that fails will issue a die. Extremely handy.

Chris
M-x auto-bs-mode

True, though I'm not a big fan a RaiseError in production code (as it sorta hides what you are trying to do). But the original code had a bare execute() outside of an eval block, and this is the key step that would be need an error check if the unique ID route was taken.

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important

my $sth = $dbh->prepare("select employee_number from employees where  
+employee_number = '$employee_number' for update");
                $sth->execute;
                my $userID = ($sth->fetchrow)[0];
 if ($userID) {
   print "This employee is already in there \n";
 }
[download]

That won't work because you're using single quotes in your prepare(), meaning you're looking for the literal string "$employee_number".Errors like this, which won't raise errors because you're executing valid SQL, can be exceedingly difficult to debug, and are avoided totally with placeholders.

As others have said, placeholders are the way to go, everywhere you can possibly use them. They automatically escape anything sketchy, also.

-Any sufficiently advanced technology is
indistinguishable from doubletalk.

Consider: my $str = "abcde '$myvar' fghi"; $myvar will interpolate because the single quotes are just characters in the double-quoted string.

All of which is beside the point since placeholders are a more robust approach.

Those aren't Perl single-quotes; since their wrapped inside double-quotes, they're literal single-quotes. Therefore $employee_number will interpolate.

However, if the employee number were actually stored in the database as a numeric type, there could be a problem with sending it as a SQL string.

Nevertheless, as you (and everyone else) has said, placeholders are a better solution.

Impossible Robot

Answer one:
I'd use COUNT, mostly because it's a fast query that would give a consistent Perl-friendly 1 or 0 in a single row. Code could look something like this:

my $check_q = "SELECT COUNT(EMPLOYEE_NUMBER) FROM EMPLOYEE WHERE EMPLO
+YEE_NUMBER = ?";
my ($employee_already_present) = $dbh->selectrow_array($check_q, undef
+, $employee_number);

if ($employee_already_present)
{
  # raise an HTML error
}
else
{ 
  # continue with the insert statement
}
[download]

Answer two:
The filter you're using may cause more problems than it solves. Since your eval is blocked instead of quoted, that extra slash will make its way into your data. You may have wanted to turn ' into '' instead (the SQL escape for '), in which case you're better off using $dbh->quote() or bind values (as in answer one above).