PL/SQL Evaluation problem of where clause in case of NUMBER column type

Question

I found the following problem in Oracle® Database 2 Day Developer's Guide 11g Release 1 (11.1) B28843-04:
The sole parameter of function eval_frequency is employee_id IN employees.employee_id%TYPE.
An ORA-01422 exception occurs when the execution reaches the following select command
SELECT e.hire_date
INTO hire_date
FROM employees e
WHERE employee_id= e.employee_id;
A possible cause of the error is that the type of employee_id is NUMBER while the employees.employee_id is NUMBER(6,0) . The result of the selection is the same as there were no WHERE clause at all.
Everything worked fine, when I declared a temporary variable of NUMBER(6,0) for storing the actual parameter of function and used this variable in the where clause, but I consider this "solution" as being no solution.
It is pointless to use %TYPE parameter of a function for flexibility if I must degrade this flexibility by a fixed declaration of a temporary variable of the same type as the column in question.
What is wrong?
The Developer'Guide I used, the Oracle Sql Developer I used or the PL/SQL version ?

Answer 1

Hi,
Welcome to the forum!
user8949829 wrote:
A possible cause of the error is that the type of employee_id is NUMBER while the employees.employee_id is NUMBER(6,0) . The result of the selection is the same as there I don't think so. The variable employee_id is defined as having the exact same type as the eponymous column. Even if it didn't, I believe Oracle will always implicity convert between datatypes when possible, rounding if necessary. That may cause errors, but it isn't causing this error.
No, the error has nothing to do with the data type. It has to do with the ambiguity of employee_id: is it a column, or is it a variable?
The default is that it means the column name, so
WHERE   employee_id = e.employee_idis equivalent to saying
WHERE   e.employee_id = e.employee_idwhich isn't quite the same thing as not having a WHERE clause; rows with NULL employee_id would still be excluded, if there were any.
I think it's best not to use variable names that are the same as column names. You could call the variable v_employee_id, or, since it's an IN-argument, in_employee_id.
If you must use a variable that can be mistaken for a column, then qulaify it with the name of the procedure, like this:
WHERE   eval_frequency.employee_id = e.employee_id
Everything worked fine, when I declared a temporary variable of NUMBER(6,0) for storing the actual parameter of function That makes sens. You probably gave that variable a name that couldn't be mistaken for a column in the table.
Edited by: Frank Kulash on Jan 12, 2011 8:27 PM