How to use Cursor's Fetch to return multiple column Data

Question

Hi ,
This is my Table :
SQL> select * from Login;
USERNAME PASSWORD CONFIRMPASSWORD
RAvi SAI SAI
Kiran Keyboard Keyboard
VARNU JAINA JAINA
This is my stored Procedure , for that Table , this is working fine , where he Cursor's Fetch is returning only a Single column of Data .
CREATE OR REPLACE PROCEDURE getEmpName(EMP_ID IN VARCHAR2)
IS
EMPNAME VARCHAR2(50);
CURSOR MYCUR
IS
SELECT USERNAME from login where USERNAME=EMP_ID;
BEGIN
OPEN MYCUR ;
LOOP
FETCH MYCUR  INTO EMPNAME;
DBMS_OUTPUT.PUT_LINE(EMPNAME);
EXIT WHEN MYCUR%NOTFOUND;
END LOOP;
close MYCUR ;
END;
Now , I have a requirement as , i need to get the Password also along with Username ,
Please tell me how can i use FETCH of Cursor to populate Details into the Declared Variables
FETCH MYCUR  INTO EMPNAME;
CREATE OR REPLACE PROCEDURE getEmpName(EMP_ID IN VARCHAR2)
IS
EMPNAME VARCHAR2(50);
PASSWORD VARCHAR2(50);
CURSOR MYCUR
IS
SELECT USERNAME , PASSWORD from login where USERNAME=EMP_ID;
BEGIN
OPEN MYCUR ;
LOOP
FETCH MYCUR  INTO EMPNAME; // Help needed here**
DBMS_OUTPUT.PUT_LINE(EMPNAME);
EXIT WHEN MYCUR%NOTFOUND;
END LOOP;
close MYCUR ;
END;
Edited by: user10503747 on Oct 14, 2010 11:51 AM
Edited by: user10503747 on Oct 14, 2010 11:52 AM

Answer 1

1) I'm hoping that this is a homework assignment. You would never, in the real world, store a password in clear text. And you would never, from a database design, have separate Password and ConfirmPassword columns.
2) The INTO clause can accept a list of variables. So
FETCH your_cursor_name INTO local_variable1, local_variable2;would be valid.
3) You would generally want to avoid having local variables that share the name of a column-- that leads to some pretty serious confusion related to scoping. One common convention is to prefix local variables with a "l_".
4) You would generally want local variables to inherit the type of the column rather than explicitly declaring the length of a string in your procedure. That way, if you change the table in the future, your code will continue to work.
5) And finally, a procedure that just calls DBMS_OUTPUT would cause all sorts of red flags in reality. It would make far more sense for this to be a function that returns a value than a procedure that tries to write to a buffer that the client application may or may not have created.
Justin