Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Passing Parameters between VFP and Stored Procedures
Message
General information
Forum:
Oracle
Category:
PL/SQL
Miscellaneous
Thread ID:
00413023
Message ID:
00413513
Views:
14
Hi Tim,
Thanks for the help. I still don't understand why this is happening. I'm going to add the EXCEPTIONS now that I have a little better grip on how that works and will check the functions you suggested. It's odd but only on those 2 variables does this happen. The UserName gets passed back correctly every time. I was thinking that perhaps I misunderstood the datatypes but that doesn't seem the case.

Anyway, thanks for the input and I will let you know if I get this figured out.

Thanks,
George

>I'm not sure what's wrong here because I normally don't return values from stored procedures.
>No reason for this I just don't normally need to do it.
>
>
>Two ideas....
>
>1) Just do it with SQLEXEC statements...in vfp upd...
>I.E.
>SQLEXEC("SELECT * FROM UserControl WHERE UserID = ?LoginID")
>
>IF password matches do the update....
> -read in access control
> -update firstin date ex...
>IF it doesn't match then password is wrong?
>
>IF Reccount()=0 No password for this ID
>
>2) There could be an exception happening....(Double check my syntax) Like I explained before once to you...
> What i am thinking is in the first statement....
> SELECT COUNT(*) INTO RecordCount
> FROM UserControl
> WHERE UserID = LoginID;
> If no rows are returned an exception occurs....
>In this case you don't know what the values will be two subbestions for this...
>a) But in the exceptions clause
>b) Set the return variables before calling this statement.
>
>Might look like....
>************************************************************************************************************'
> create or replace procedure pCheckLogin
> (LoginID IN VARCHAR2,
> ePassWord IN VARCHAR2,
> InUserName IN OUT VARCHAR2,
> InSource IN OUT VARCHAR2,
> InAccessLevel IN OUT VARCHAR2,
> RetVal IN OUT NUMBER)
>AS
>
> TablePword UserControl.Password%TYPE;
> RecordCount NUMBER;
> CurrentDate DATE;
> NumTimesIn NUMBER;
>
> BEGIN
> accesslevel:="";
> RetVal:=1;
>
> SELECT COUNT(*) INTO RecordCount
> FROM UserControl
> WHERE UserID = LoginID;
>
> IF RecordCount > 0 THEN
>
> SELECT Password INTO TablePword
> FROM UserControl
> WHERE UserID = LoginID;
>
> IF TablePword=ePassWord THEN
> /* password matches */
> RetVal := 0;
> SELECT RTRIM(username), RTRIM(source), RTRIM(accesslevel)
> INTO InUserName, InSource, InAccessLevel
> FROM UserControl
> WHERE UserID = LoginID;
>
> SELECT timesin INTO NumTimesIn
> FROM usercontrol
> WHERE UserID = LoginID;
> IF NumTimesIn = 0 THEN
> UPDATE UserControl
> SET FirstIn = SYSDATE
> WHERE UserID = LoginID;
> END IF;
> NumTimesIn := NumTimesIn + 1;
> UPDATE UserControl
> SET loggedin=1, lastin=SYSDATE, TimesIn=NumTimesIn
> WHERE UserID = LoginID;
> COMMIT;
> ELSE
> /* password does not match */
> RetVal := -1;
> END IF;
> ELSE
> /* No password for this ID */
> RetVal := -2;
> END IF;
>EXCEPTIONS
> WHEN OTHERS THEN
> RetVal := -1;
> accesslevel:="";
>
>END;
>
>But as far as what mark has said it should be possible to do anything to the variables you want and have the values returned.
>You should know one thing.
>If you call the function with "user " for example
>oracle will strip away the spaces and use "user" that's just the way it works and I never get concerned about this but as I see the
>strange characters are a problem and the stored procedure I would say is suspect...
>
>Coding idea...
>look at DBMS_SQL and DECODE....
>But you stored procedure should be fine...
Everything we see or seems
Is but a dream within a dream
- Edgar Allen Poe
Previous
Reply
Map
View

Click here to load this message in the networking platform