I have created procedure to check and validate username and password, even when I provide correct password I will receive always exception error. I tried different thing inside the procedure but results would be the same.
create or replace
PROCEDURE member_ck_sp
(p_uname IN VARCHAR2,
p_pass IN VARCHAR2,
p_name OUT VARCHAR2,
p_cookie OUT VARCHAR2)
IS
CURSOR CUR_CHECK IS
SELECT USERNAME, PASSWORD,FIRSTNAME||''||LASTNAME, COOKIE
FROM bb_shopper;
lv_check_txt VARCHAR2(100);
BEGIN
FOR rec_check IN cur_check LOOP
IF p_uname = rec_check.username
AND p_pass = rec_check.PASSWORD THEN
lv_check_txt := 'Pass';
ELSE lv_check_txt := 'Fail';
END IF;
END LOOP;
IF lv_check_txt = 'Pass' THEN
SELECT FIRSTNAME||''||LASTNAME, COOKIE
INTO p_name, p_cookie
FROM bb_shopper
WHERE USERNAME = P_UNAME
AND password = p_pass;
dbms_output.put_line(p_name||' '|| p_cookie);
ELSE raise no_data_found;
END IF;
--dbms_output.put_line(p_name||' '|| p_cookie);
EXCEPTION
WHEN no_data_found THEN
dbms_output.put_line('Please reneter credentials');
END;
And block to check code:
DECLARE
lv_username_txt bb_shopper.username%TYPE := 'rat55';
lv_password_txt bb_shopper.PASSWORD%TYPE := 'kile';
lv_name_txt VARCHAR2(200);
lv_cookie_txt bb_shopper.cookie%TYPE;
BEGIN
member_ck_sp(lv_username_txt,lv_password_txt,lv_name_txt,lv_cookie_txt);
--DBMS_OUTPUT.PUT_LINE('User name is '||lv_name_txt||' and
cookie '||lv_cookie_txt);
END;
Your problem is the opening LOOP reads all the records in bb_shopper. One of those records presumably matches the entered credentials. However, unless the last record read is the matching one, you will exit the loop with lv_check_txt = 'Fail'. And that's why you always fail the test in the subsequent IF and get no_data_found.
The solution seems quite simple: ditch the loop and just validate the passed parameters.
create or replace
PROCEDURE member_ck_sp
(p_uname IN VARCHAR2,
p_pass IN VARCHAR2,
p_name OUT VARCHAR2,
p_cookie OUT VARCHAR2)
IS
BEGIN
SELECT FIRSTNAME||''||LASTNAME, COOKIE
INTO p_name, p_cookie
FROM bb_shopper
WHERE USERNAME = P_UNAME
AND password = p_pass;
--dbms_output.put_line(p_name||' '|| p_cookie);
EXCEPTION
WHEN no_data_found THEN
raise_application_error(-20000, 'Please re-enter credentials');
END;
I haven't looked at PL\SQL in a long time. However, my first suggestion would be to look at your test data:
SELECT * FROM bb_shopper where username = 'rat55';
A few things to keep in mind:
The last line in the block to check code was probably meant to be commented out. It contains a quotation mark left open and a close bracket without an opening bracket. That can't help.
I'll take a different tack on this one. I see one potential error that overrides anything regarding the syntax and functionality, and that is:
I really really REALLY hope you are not planning on storing cleartext passwords in a database table.
Do not ever do this....ever. Please tell us that this routine already has the password salted/hashed before making it to this routine and table. Otherwise, this is the first thing you should looking at fixing before anything else.
Related
I am facing 'ORA-01002: fetch out of sequence' error as a value for 'P_RESPONSE' cursor. It doesn't matter if select query returns any records, error is there in the output every single time.
Please note that 'REQUESTSUBMITTERS.USERNAME' is a primary key.
PFB Stored Procedure.
create or replace PROCEDURE GET_REQUESTSUBMITTER (
P_USERNAME IN REQUESTSUBMITTERS.USERNAME%TYPE,
P_RESPONSE OUT SYS_REFCURSOR,
SPRESULT OUT VARCHAR2,
SPRESPONSECODE OUT VARCHAR2,
SPRESPONSEMESSAGE OUT VARCHAR2
)
AS
L_REQUESTSUBMITTER REQUESTSUBMITTERS%ROWTYPE;
BEGIN
OPEN P_RESPONSE FOR
SELECT USERNAME, GEN, FIRSTNAME, LASTNAME, EMAILID, OFFICELOCATION, TITLE, MANAGER, DEPARTMENT
FROM REQUESTSUBMITTERS
WHERE UPPER(USERNAME)=UPPER(P_USERNAME);
LOOP
EXIT WHEN P_RESPONSE%NOTFOUND;
FETCH P_RESPONSE INTO L_REQUESTSUBMITTER;
END LOOP;
IF P_RESPONSE%ROWCOUNT=0 THEN
OPEN P_RESPONSE FOR
SELECT 'NA' AS USERNAME FROM DUAL;
SPRESULT:='NOK';
SPRESPONSECODE:='GETREQSUBMTR-002';
SPRESPONSEMESSAGE:=CONCAT('SUBMITTER RECORD NOT FOUND FOR USER - ', P_USERNAME);
ELSE
SPRESULT:='OK';
SPRESPONSECODE:='GETREQSUBMTR-001';
SPRESPONSEMESSAGE:=CONCAT('SUBMITTER RECORD FOUND FOR USER - ', P_USERNAME);
END IF;
END GET_REQUESTSUBMITTER;
I believe your EXIT statement should be after the FETCH statement inside the loop, else you'll loop past the end.
Don't forget to CLOSE the cursor.
Do the following changes and see if your procedure works
create or replace PROCEDURE GET_REQUESTSUBMITTER (
P_USERNAME IN REQUESTSUBMITTERS.USERNAME%TYPE,
P_RESPONSE OUT SYS_REFCURSOR,
SPRESULT OUT VARCHAR2,
SPRESPONSECODE OUT VARCHAR2,
SPRESPONSEMESSAGE OUT VARCHAR2
)
AS
L_REQUESTSUBMITTER REQUESTSUBMITTERS%ROWTYPE;
L_ROW_CNT NUMBER;
BEGIN
OPEN P_RESPONSE FOR
SELECT USERNAME, GEN, FIRSTNAME, LASTNAME, EMAILID, OFFICELOCATION, TITLE, MANAGER, DEPARTMENT
FROM REQUESTSUBMITTERS
WHERE UPPER(USERNAME)=UPPER(P_USERNAME);
LOOP
FETCH P_RESPONSE INTO L_REQUESTSUBMITTER;
EXIT WHEN P_RESPONSE%NOTFOUND;
END LOOP;
L_ROW_CNT:= P_RESPONSE%ROWCOUNT;
CLOSE P_RESPONSE;
IF L_ROW_CNT=0 THEN
OPEN P_RESPONSE FOR
SELECT 'NA' AS USERNAME FROM DUAL;
SPRESULT:='NOK';
SPRESPONSECODE:='GETREQSUBMTR-002';
SPRESPONSEMESSAGE:=CONCAT('SUBMITTER RECORD NOT FOUND FOR USER - ', P_USERNAME);
CLOSE P_RESPONSE;
ELSE
SPRESULT:='OK';
SPRESPONSECODE:='GETREQSUBMTR-001';
SPRESPONSEMESSAGE:=CONCAT('SUBMITTER RECORD FOUND FOR USER - ', P_USERNAME);
END IF;
END GET_REQUESTSUBMITTER;
I am fairly new to PL/SQL and one of the doubts I have is to create and declare functions.
Specifically this one:
Create a function that creates a new user:
Use a sequence togive the new User a new ID
Pass the name, address, etc... as IN arguments
Return as OUT arguments the ID created and a O_ERROR_MESSAGE
Function returns TRUE if the user is added, otherwise returns FALSE
Handle exceptions
Create a PL/SQL block and test the created function
This is my code so far:
CREATE OR REPLACE FUNCTION DSB_ADD_NEW_USERS (I_NAME IN VARCHAR2,
I_ADDRESS IN VARCHAR2,
I_BIRTHDATE IN DATE,
I_COUNTRY IN VARCHAR2)
RETURN NUMBER IS
O_ERROR_MESSAGE EXCEPTION;
CURRENT_USER NUMBER;
BEGIN
DSB_NB_SEQ_USER_ID.NEXTVAL;
SELECT COUNT(USER_ID) INTO CURRENT_USER
FROM DSB_NB_USERS;
WHILE CURRENT_USER != 0
LOOP
DSB_NB_SEQ_USER_ID.NEXTVAL;
SELECT COUNT(USER_ID) INTO CURRENT_USER
FROM DSB_NB_USERS;
END LOOP;
INSERT INTO DSB_NB_USERS (USER_ID, NAME, ADDRESS, BIRTHDATE, COUNTRY_ID_FK) VALUES (CURRENT_USER, I_NAME, I_ADDRESS, TO_DATE('I_BIRTHDATE', 'DD/MM/YYYY'), I_COUNTRY);
RETURN CURRET_USER;
EXCEPTION
WHEN O_ERROR_MESSAGE THEN
RETURN NULL;
WHEN OTHERS THEN
RETURN NULL;
END;
DECLARE
I_NEW_USER NUMBER;
BEGIN
I_NEW_USER := DSB_ADD_NEW_USERS(I_NAME => 'Arnaldo Amaral',
I_ADDRESS => 'Rua da Agra',
I_BIRTHDATE => '03/05/1959',
I_COUNTRY => 'PT');
END;
Am i too far from the truth?
I know there's still a lot to add.
Thank you for the help!!!
It seems to me you are asking for a lifeline, that needs more than just a code response. First off look at the answer by
#Tejash. His solution is a far cry from what you have, and is correct for your function definition (although that is itself incorrect given your listed requirements.) Also, #EdStevens is correct that is is a very poor use of a function. However a function is your assignment's requirement.
So lets dissect your code and see how it satisfies each of your requirements. (I cannot stand all caps, so I'm lower casing it.)
Fails. While you have a sequence it is used improperly. You can not
just code a standalone name. It must be used in either a SQL
statement or an assignment statement.
Passes.
Fails. Your function passes the IN parameters correctly. However
there are no OUT parameters.
Your function returns Number not the required True/False which
requires either Boolean or varchar2 for literal.
Code section for requirements 3,4.
create or replace function dsb_add_new_users (i_name in varchar2,
i_address in varchar2,
i_birthdate in date,
i_country in varchar2) <<< where are the 2 required out parameters
return number is <<< Should be True or False so either Boolean or varchar2
o_error_message exception; <<< Should be an Out parameter not an exception
Yes you have the Exception Section, which is required for handling
exceptions. However you do not handle exceptions so much as suppress
them, indicating to Oracle, and to the calling routine, that they didn't actually happen.
exception
when o_error_message then <<< as coded this is a developer defined exception, yet is not raised so it cannot happen.
return null; <<< even if it were raised you have thrown it away, the calling routine will never it happened
when others then <<< One of the worst pieces of code that can be written. I tend to remember seeing a discussion in
return null; <<< Oracle that would make this a compile time error. To bad the supporters lost the argument.
Passed, mostly. Correct for posted code, but insufficient per requirements.
So all-in-all not highly successful when viewed against the requirements.
A couple other items not specific the requirements, but disaster to successful implementation.
While technically you might get away with the following it is very bad practice. Current_User is an Oracle reserved word.
current_user number; <<< NO, NO bad verifiable name.
The following completely decimates your function. It creates a never ending loop. Well not quite -- it runs 1 time, but never afterward.
I believe you intended for the current_user variable to contain the ID assigned to the user. But it actually contains the number of rows in the table. Further what would the number of rows (count) have to do with Inserting a row? SO what does the code actually Do?
dsb_nb_seq_user_id.nextval; <<< systax error.
select count(user_id) into current_user <<< count the number of rows in the table
from dsb_nb_users;
while current_user != 0 <<< if there are any rows in the table
loop
dsb_nb_seq_user_id.nextval; <<< syntax error
select count(user_id) into current_user <<< try counting then again until there are none.
from dsb_nb_users;
end loop;
So correcting for the above what do we wind up with. I hesitate here in fear you will just copy the below and submit it. Please don't do that but study and understand what it's doing, then rewrite you routine. But after tearing you initial effort up, I guess I owe a corrected solution.
create or replace function dsb_add_new_users
( i_name in varchar2
, i_address in varchar2
, i_birthdate in date
, i_country in varchar2
, o_new_user_id out number
, o_error_message out varchar2
return boolean
is
country_id_l number;
begin
-- initialize out variables
o_new_user_id := null;
o_error_message := null;
-- get country id from input parameter
select country_id
into country_id_l
from country
where name = i_country;
-- create user and get the assigned user_id
insert into dsb_nb_users (user_id, name, address, birthdate, country_id_fk)
values dsb_nb_seq_user_id.nextval
, i_name
, i_address
, i_birthdate
, country_id_l
)
returning user_id
into o_new_user_id;
return true;
exception
when no_date_found then
o_output_message = 'ERROR: Specified country name ''' || country_id_l || ''' Not Found.';
return false;
when others then
o_output_message := 'ERROR: ' || sqlerrm;
return false
end dsb_add_new_users ;
--------------- Test Driver ----------------
declare
i_new_user number;
new_user_created boolean;
error_message varchar2(255);
begin
new_user_created := dsb_add_new_users( i_name => 'Arnaldo Amaral',
, i_address => 'Rua da Agra'
, i_birthdate => to_date('03/05/1959','mm/dd/yyyy') -- or is it 'dd/mm/yyyy'
, i_country => 'PT'
, o_new_user_id => i_new_user
, o_error_message => error_message);
if not new_user_created
then
dbms_output.put_line (error_messag);
end if ;
end;
Disclaimer: As you did not post table DDL nor test data the routine has not been tested nor even compiled. Any syntax error(s) is for you to resolve. Further, I follow Tejash in the assumption you actually have a countries table and there is a FK to it. That may be an erroneous assumption.
Why don't you directly use the sequence value to insert new user as follows:
CREATE OR REPLACE FUNCTION DSB_ADD_NEW_USERS (
I_NAME IN VARCHAR2,
I_ADDRESS IN VARCHAR2,
I_BIRTHDATE IN DATE,
I_COUNTRY IN VARCHAR2
) RETURN NUMBER IS
CURRENT_USER_ID NUMBER;
BEGIN
CURRENT_USER_ID := DSB_NB_SEQ_USER_ID.NEXTVAL; -- returns new and unique number
INSERT INTO DSB_NB_USERS (
USER_ID,
NAME,
ADDRESS,
BIRTHDATE,
COUNTRY_ID_FK
) VALUES (
CURRENT_USER_ID,
I_NAME,
I_ADDRESS,
I_BIRTHDATE,
(
SELECT
COUNTRY_ID
FROM
COUNTRIES
WHERE
NAME = I_COUNTRY
) -- it is FK so need to use SELECT sub-query to find COUNTRY_ID
);
RETURN CURRENT_USER_ID; -- returning the new user ID
EXCEPTION
WHEN OTHERS THEN
RETURN -1; -- returning -1 in case there is any error
END;
-1 will be returned when there is an error while adding the new user.
Came up with this much simpler answer after asking to a few people for help.
create or replace FUNCTION DSB_ADD_NEW_USERS (I_NAME IN VARCHAR2,
I_ADDRESS IN VARCHAR2,
I_BIRTHDATE IN DATE,
I_COUNTRY IN VARCHAR2)
RETURN NUMBER IS
CURRENT_USER NUMBER;
BEGIN
CURRENT_USER := DSB_NB_SEQ_USER_ID.NEXTVAL;
DBMS_OUTPUT.PUT_LINE('Hello World');
INSERT INTO DSB_NB_USERS (USER_ID, NAME, ADDRESS, BIRTHDATE, COUNTRY_ID_FK) VALUES (CURRENT_USER, I_NAME, I_ADDRESS, TO_DATE(I_BIRTHDATE, 'DD/MM/YYYY'), I_COUNTRY);
RETURN CURRENT_USER;
EXCEPTION
WHEN OTHERS THEN
RETURN -1;
END;
SET SERVEROUT ON
DECLARE
I_NEW_USER NUMBER;
BEGIN
I_NEW_USER := DSB_ADD_NEW_USERS(I_NAME => 'Arnaldo Amaral',
I_ADDRESS => 'Rua da Agra',
I_BIRTHDATE => '03/MAY/1959',
I_COUNTRY => 'PT');
commit;
END;
/
Thank you all!!!
I have procedure like below, but when block is run it does not shows message for error if data is not found.
CREATE OR REPLACE
PROCEDURE DDPROJ_SP
(P_IDPROJ IN DD_PROJECT.IDPROJ%TYPE,
P_INFO OUT VARCHAR2,
p_check OUT VARCHAR2)
IS
CURSOR cur_ddproj IS
SELECT *
FROM dd_project
WHERE idproj = p_idproj;
lv_projinfo_txt VARCHAR2(100);
BEGIN
FOR rec_ddproj IN cur_ddproj LOOP
lv_projinfo_txt := (rec_ddproj.idproj||', '||rec_ddproj.projname||
', '||rec_ddproj.projstartdate||', '||rec_ddproj. projenddate||
', '||rec_ddproj.projfundgoal||', '||rec_ddproj.p rojcoord);
END LOOP;
P_INFO := LV_PROJINFO_TXT;
EXCEPTION
WHEN NO_DATA_FOUND THEN
P_CHECK :='Please select another project';
DBMS_OUTPUT.PUT_LINE(P_CHECK);
END;
And block:
DECLARE
LV_INFO_TXT VARCHAR2(100);
LV_CHECK_TXT VARCHAR2(30);
BEGIN
DDPROJ_SP(00,lv_info_txt,lv_check_txt);
DBMS_OUTPUT.PUT_LINE(LV_INFO_TXT);
END;
After RUNNING BLOCK IF id provided is correct I would receive requested information but if ID is not found exception will not show message on print.
Firstly, as has been pointed out, your exception handler doesn't do anything really visible except call dbms_output, the results of which you'll only see if you set serverout on or otherwise access the results from dbms_output.
Secondly and more importantly, when you use a FOR loop to process the results of a cursor, the NO_DATA_FOUND exception will never be raised.
If you want to detect no rows found, you have a few options:
After the loop, check if the variable was set, e.g.:
...
end loop;
if lv_projinfo_txt is null then
raise no_data_found;
end if;
If you don't expect more than 1 record to be found by the query (which is suggested by your predicate on an "id"), you can avoid the FOR loop and use a simple select into:
PROCEDURE DDPROJ_SP
(P_IDPROJ IN DD_PROJECT.IDPROJ%TYPE,
P_INFO OUT VARCHAR2,
p_check OUT VARCHAR2)
IS
rec_ddproj dd_project%rowtype;
lv_projinfo_txt VARCHAR2(100);
BEGIN
SELECT *
into rec_ddproj
FROM dd_project
WHERE idproj = p_idproj;
lv_projinfo_txt := (rec_ddproj.idproj||', '||rec_ddproj.projname||
', '||rec_ddproj.projstartdate||', '||rec_ddproj.projenddate||
', '||rec_ddproj.projfundgoal||', '||rec_ddproj.projcoord);
P_INFO := LV_PROJINFO_TXT;
EXCEPTION
WHEN NO_DATA_FOUND THEN
P_CHECK :='Please select another project';
DBMS_OUTPUT.PUT_LINE(P_CHECK);
END;
Notes:
A select into may raise NO_DATA_FOUND or TOO_MANY_ROWS.
Good practice is to never handle errors without re-raising the exception, unless your code actually handles the exception. In your case, your code merely sends a signal back to the calling process via the p_check parameter, which moves responsibility for handling the error to the caller. This might be ok in some circumstances but it assumes the caller actually heeds the signal. It would be better to raise an exception which forces the caller to handle it appropriately.
Good practice is to alias all columns and parameters in a query; having a SQL predicate like idproj = p_idproj makes the assumption that the table will never have a column called p_idproj in the future. Instead, it's good practice to deliberately alias all columns and parameters, e.g.
SELECT x.*
into rec_ddproj
FROM dd_project x
WHERE x.idproj = ddproj_sp.p_idproj;
I am trying to get the user_id and group_id for individual user.
I have used user's email in loop because so many users are there, but I need the loop should take one by one, currently its taking all mail ids like : abinnaya.moorthy#abc.com,abinnaya.moorthy#def.com.
Because of this the select query is not returning any value.
The select query should return the value one by one by taking the email id from loop.
code:
DECLARE
L_USERS varchar2(1000);
l_org_group_id varchar2(1000);
l_user_id varchar2(1000);
l_api_body varchar2(1000);
l_retry_after number;
l_status number;
L_NOT_PROVISIONED_USERS varchar2(1000);
l_success boolean;
l_user varchar2(1000);
BEGIN
FOR I IN
(Select REQUESTORS_NAME into L_USER
from Request
where Request_Status = 'Approved'
and Provisioning_Status is NULL )
LOOP
L_USER:= L_USER ||','||I.REQUESTORS_NAME;
select GROUP_ID INTO l_org_group_id
from WORKSPACE_GROUP
where LOWER(email)=(L_USER);
select USER_ID into l_user_id
from slackdatawarehouse.users
where lower(email) = lower(L_USER);
DBMS_OUTPUT.PUT_LINE(l_user_id);
if l_user_id is null then
l_not_provisioned_users := l_not_provisioned_users||','|| L_USER;
else
l_api_body := l_api_body || '{"value" :"'||l_user_id ||'"},';
l_users := l_users||','||l_user_id;
end if;
end loop;
end;
Help me to get the user email one by one and pass it in select query to get the groupid and user id.
Oh, boy. I presume that senior members / moderators won't be too happy with this "answer", but it is impossible to put everything into a 600-characters long comment. True, I could shorten the critic to "this is sh*t", but that won't help anyone. Though, "rules" would be obeyed. So, if it turns out that this message is deleted, sorry, everyone.
Here you go.
It is difficult to guess what you want to get as the result. You talk about Apex, but - what does this code have to do with it? DBMS_OUTPUT certainly won't work there.
Then, in DECLARE section, you use 3 variables that are never used - get rid of them.
Cursor FOR loop is the way to do that; however, remove INTO clause from SELECT, it doesn't belong here.
L_USER is concatenation of all REQUESTOR_NAMEs returned by cursor. It means that you shouldn't use it in SELECT GROUP_ID nor SELECT USER_ID statements as it certainly won't return anything (maybe something for the first loop iteration, but nothing for the rest of them). It looks as if you'd rather use I.REQUESTORS_NAME. Also, once you apply LOWER function to it, and then you don't - consider making it uniform.
Why do you select GROUP_ID at all? You never use it later.
L_NOT_PROVISIONED_USERS is a huge concatenation of duplicates, as you concatenate previous values with (yet another concatenation of) L_USER. Try to DBMS_OUTPUT it, you'll see.
You don't care about possible NO-DATA-FOUNDs which might well be raised by those SELECTs, as - as I've already said - they won't return anything in subsequent loop iterations.
Finally, even if that PL/SQL finishes successfully, it won't do anything. Nobody, including you, wont' benefit from it.
So, this is quite a mess ... try to follow what I've written, make a clear picture of what you want to get as a result, go step-by-step, test frequently and - hopefully - you'll get something useful.
Do it as below:
DECLARE
L_USERS VARCHAR2 (1000);
L_ORG_GROUP_ID VARCHAR2 (1000);
L_USER_ID VARCHAR2 (1000);
L_API_BODY VARCHAR2 (1000);
L_RETRY_AFTER NUMBER;
L_STATUS NUMBER;
L_NOT_PROVISIONED_USERS VARCHAR2 (1000);
L_SUCCESS BOOLEAN;
L_USER VARCHAR2 (1000);
CURSOR EMAIL_IDS
IS
SELECT REQUESTORS_NAME L_USER
FROM REQUEST
WHERE REQUEST_STATUS = 'Approved'
AND PROVISIONING_STATUS IS NULL;
BEGIN
FOR I IN EMAIL_IDS
LOOP
SELECT GROUP_ID
INTO L_ORG_GROUP_ID
FROM WORKSPACE_GROUP
WHERE LOWER (EMAIL) = LOWER (I.L_USER);
SELECT USER_ID
INTO L_USER_ID
FROM SLACKDATAWAREHOUSE.USERS
WHERE LOWER (EMAIL) = LOWER (I.L_USER);
DBMS_OUTPUT.PUT_LINE (L_USER_ID);
IF L_USER_ID IS NULL THEN
L_NOT_PROVISIONED_USERS :=
L_NOT_PROVISIONED_USERS || ',' || I.L_USER;
ELSE
L_API_BODY :=
L_API_BODY || '{"value" :"' || L_USER_ID || '"},';
L_USERS := L_USERS || ',' || L_USER_ID;
END IF;
END LOOP;
EXCEPTION
WHEN OTHERS THEN
DBMS_OUTPUT.PUT_LINE (SQLERRM);
END;
I need to get the output in uu in accordance with value passed through the prompt
create or replace procedure chklg( uu out logn.username%TYPE
, pass in logn.password%TYPE)
is
begin
select username into uu from logn where password=pass;
end;
I tried executing the above procedure this way:
begin
chklg(:pass);
end
By definition a procedure doesn't return anything. You're looking for a function.
create or replace function chklg ( p_pass in logn.password%TYPE
) return varchar2 is -- assuming that logn.username%TYP is a varchar2
l_uu logn.username%type;
begin
select username into l_uu from logn where password = p_pass;
return l_uu;
-- If there-s no username that matches the password return null.
exception when no_data_found then
return null;
end;
I'm slightly worried by this as it appears as though you're storing a password as plain text. This is not best practice.
You should be storing a salted and peppered hash of your password next to the username, then apply the same salting, peppering and hashing to the password and select the hash from the database.
You can execute the function either of the following two ways:
select chklg(:pass) from dual
or
declare
l_pass logn.password%type;
begin
l_pass := chklg(:pass);
end;
/
To be complete Frank Schmitt has raised a very valid point in the comments. In addition to you storing the passwords in a very dangerous manner what happens if two users have the same password?
You will get a TOO_MANY_ROWS exception raised in your SELECT INTO .... This means that too many rows are returned to the variable. It would be better if you passed the username in as well.
This could make your function look something like the following
create or replace function chklg (
p_password_hash in logn.password%type
, p_username in logn.username%type
) return number
/* Authenticate a user, return 1/0 depending on whether they have
entered the correct password.
*/
l_yes number := 0;
begin
-- Assumes that username is unique.
select 1 into l_yes
from logn
where password_hash = p_password_hash
and username = p_username;
return l_yes;
-- If there-s no username that matches the password return 0.
exception when no_data_found then
return 0;
end;
If you're looking to only use a procedure (there's no real reason to do this at all as it unnecessarily restricts you; you're not doing any DML) then you can get the output parameter but you have to give the procedure a parameter that it can populate.
In your case it would look something like this.
declare
l_uu logn.username%type;
begin
chklg(l_uu, :pass);
dbms_output.put_line(l_uu);
end;