I have a stored procedure in a Oracle Database that receives 3 parameters.
I know that I call it with 1 to 3 parameters but it's possible to know inside itself how many arguments are the defaults or are really passed?
For example:
dummy(1) some keyword say me "1"
dummy(1,2,3) say me "3"
I ask this because I worked with Informix 4GL and I could use "NARGS" to know the number of arguments that I receive.
The short answer is no.. there is not an equivalent to NARGS or "C"s argc.
if you are using null default values you could manually count the number of arguments that do no equal the default value.. but that wont tell you if you explicitly pass the default value as a parameter.
i can think of 2 solutions.
1. user overloaded procedures .. ie
procedure a (p_1 number);
procedure a (p_1 number, p_2 number);
procedure a (p_1 number, p_2 number, p_3 number);
then in the bodies you would "know" by which one you are in.
option 2. pass a varray/plsql table as a single argument but then actually passing the arguments becomes problematic.
create or replace package x
is
type an_arg is record ( n number, v varchar2(2000), d date);
type args is table of an_arg;
procedure a(argv args);
end;
/
create or replace package body x
is
procedure a(argv args)
is
begin
dbms_output.put_line('i was passed '||argv.count||' arguments');
end;
end;
/
Similar to ShoeLace's answer, I think counting the number of parameters that do not equal the default of each parameter would work.
The key to this is to give each parameter a nonsensical default value. Like '~#dummee_v#1u3#~' maybe. Anything you are confident will never actually be passed in. This way you don't have to worry about somebody passing in a parameter value that equals the default value.
So:
create procedure p1 (id1 varchar2 default '~#dummee_v#1u3#~', id2 varchar2 default '~#dummee_v#1u3#~') is
lParamCount number := 0;
lDummyParamValue varchar2 := '~#dummee_v#1u3#~';
begin
if id1 <> lDummyParamValue then lParamCount := lParamCount + 1;
if id2 <> lDummyParamValue then lParamCount := lParamCount + 1;
end p1;
Related
I am writing unit tests for an existing procedure which has boolean parameters. As the tests run, they will store the associated parameter values in a table. I want to use variables for setting the parameter columns in the table and to pass to the procedure. Is there a way to go from an integer (what I'll set in my table) to the procedure (which requires boolean values)?
I've tried passing 1/0 values and the strings "TRUE" and "FALSE" to the procedure. I've tried making my table use a boolean datatype for the relevant columns. I've tried CASTing. I've tried using a SELECT INTO with CASE statement to set a different boolean-type variable based on the value of the integer-type variable.
CREATE TABLE UNIT_TEST_RESULTS (
case VARCHAR2(50)
,includeLines NUMBER(1) --this will hold the value of i_includeLines below
,result VARCHAR2(4)
);
CREATE OR REPLACE PROCEDURE X_UNIT_TEST AS
i_includeLines NUMBER(1)
BEGIN
i_includeLines:=0;
X_THING_TO_TEST(includeLinesBool=>i_includeLines);
/*...analyze output...*/
INSERT INTO UNIT_TEST_RESULTS(case,includeLines,result)
VALUES ('test',i_includeLines,'fail'); COMMIT;
END X_UNIT_TEST;
I'd probably do something like
i_includeLines NUMBER(1)
b_includeLines boolean;
BEGIN
i_includeLines:=0;
b_includeLines := (case i_includeLines when 1 then true else false end);
X_THING_TO_TEST(includeLinesBool=>b_includeLines);
or
b_includeLines boolean;
i_includeLines integer;
BEGIN
b_includeLines:= false;
X_THING_TO_TEST(includeLinesBool=>b_includeLines);
/*...analyze output...*/
i_includeLines := case when b_includeLines = true then 1 else 0 end;
INSERT INTO UNIT_TEST_RESULTS(case,includeLines,result)
VALUES ('test',i_includeLines,'fail');
COMMIT;
Obviously, either of these case statements could (and should) get encapsulated into a function assuming you are going to call them regularly.
I would suggest that you not use the reserved word case for a column name-- that's going to bite you at some point. I'm also not a fan of the Hungarian notation for variable names but that's more of a religious debate...
There is no implicit conversion from numbers or strings to Boolean, but a simple true/false expression like i_includeLines = 1 evaluates to Boolean true if i_includeLines has the value 1, so you could call your procedure like this:
x_thing_to_test(includeLinesBool => i_includeLines = 1);
That will pass true if i_includeLines is 1, false if it is not 1, else null.
If you need to treat null as false then you'll need a case/coalesce/nvl or similar expression.
There's no Boolean in your code so - here's how I understood the question:
You have a procedure which accepts parameter that is Boolean:
SQL> create or replace procedure p_test
2 (par_bool in boolean)
3 is
4 begin
5 null;
6 end;
7 /
Procedure created.
SQL>
You want to call it; there's some number variable (l_int in my example) and you'd want to convert it to Boolean and pass as such to the p_test procedure. Here's how:
SQL> declare
2 l_int integer := 1;
3 begin
4 p_test(case when l_int = 1 then true else false end);
5 end;
6 /
PL/SQL procedure successfully completed.
SQL>
I read about IN OUT and NOCOPY. Then I encountered NOCOPY use cases but I was not able to get it. Can anybody explain these with examples? Thanks in advance.
The actual parameter must be implicitly converted to the data type of the formal parameter.
The actual parameter is the element of a collection.
The actual parameter is a scalar variable with the NOT NULL constraint.
The actual parameter is a scalar numeric variable with a range, size, scale, or precision constraint.
The actual and formal parameters are records, one or both was declared with %ROWTYPE or %TYPE, and constraints on corresponding fields differ.
The actual and formal parameters are records, the actual parameter was declared (implicitly) as the index of a cursor FOR LOOP statement, and constraints on corresponding fields differ.
The subprogram is invoked through a database link or as an external subprogram.
The basic principle is that PL/SQL will honour the NOCOPY directive as long as the value we pass can be used as provided, without transformation, and is addressable by the called program. The scenarios you list are circumstances where this is not the cases. I must admit a couple of these examples made me think, so this is a worthwhile exercise.
The first four examples call this toy procedure.
create or replace procedure tst2 (p1 in out nocopy t34%rowtype) is
begin
p1.id := 42;
end;
/
Case 1: The actual parameter must be implicitly converted to the data type of the formal parameter.
declare
n varchar2(3) := '23';
begin
tst(n);
dbms_output.put_line(n);
end;
/
Case 2: The actual parameter is the element of a collection.
declare
nt sys.odcinumberlist := sys.odcinumberlist(17,23,69);
begin
tst(nt(2));
dbms_output.put_line(to_char(nt(2)));
end;
/
Case 3: The actual parameter is a scalar variable with the NOT NULL constraint.
declare
n number not null := 23;
begin
tst(n);
dbms_output.put_line(to_char(n));
end;
/
Case 4: The actual parameter is a scalar numeric variable with a range, size, scale, or precision constraint.
declare
n number(5,2) := 23;
begin
tst(n);
dbms_output.put_line(to_char(n));
end;
/
The next example uses this table ...
create table t34 (id number not null, col1 date not null)
/
...and toy procedure:
create or replace procedure tst2 (p1 in out nocopy t34%rowtype) is
begin
p1.id := 42;
end;
/
Case 5 : The actual and formal parameters are records, one or both was declared with %ROWTYPE or %TYPE, and constraints on corresponding fields differ.
declare
type r34 is record (id number, dt date);
r r34;
begin
r.id := 23;
r.dt := to_date(null); --trunc(sysdate);
tst2(r);
dbms_output.put_line(to_char(r.id));
end;
/
The next example uses this package spec...
create or replace package pkg is
type r34 is record (id number, dt date);
end;
/
...and toy procedure:
create or replace procedure tst3 (p1 in out nocopy pkg.r34) is
begin
p1.id := p1.id + 10;
end;
/
Case 6: The actual and formal parameters are records, the actual parameter was declared (implicitly) as the index of a cursor FOR LOOP statement, and constraints on corresponding fields differ.
begin
for j in ( select * from t34) loop
tst3(j);
dbms_output.put_line(to_char(j.id));
end loop;
end;
/
The last example uses a remote version of the first procedure.
Case 7: The subprogram is invoked through a database link or as an external subprogram.
declare
n number := 23;
begin
tst#remote_db(n);
dbms_output.put_line(to_char(n));
end;
/
There are working demos of the first six cases on db<>fiddle here.
I have procedure A, which has some in and out parameters. I can't change parameters or code of first procedure, but I need to get different result. I decided to create procedure B, which will pass additional parameter. I want to call procedure A from this procedure and handle result of procedure A in it. I know type of parameters, which procedure A returns.
I need somethink like this:
procedure A(id in number, names out names_array) is
begin
// procedure A body
// filling names var
end;
procedure B (id in number, myLimit in number, names out names_array) is
temp_names names_array;
i integer;
begin
A(id => id, names => temp_names);
while i < myLimit loop
names(i) := temp_names(i);
end loop;
end;
So the problem is in handling names (the result of procedure A). How I can do this correctly? Maybe with some select ... limit myLimit query?
Definition of names_array:
TYPE names_array IS TABLE OF VARCHAR2 (40)
INDEX BY BINARY_INTEGER;
I'm attempting to write a stored procedure in Oracle (which I have come to hate (beside the point))
When executing the stored proc I'm told I've retrieved too many rows (eg. more than 1), but when querying the data via text, it tells me clearly that only one row matches this criteria.
create or replace
PROCEDURE GETADDRESSCOORDS
(
HOUSE IN VARCHAR2
, STREET IN VARCHAR2
, X OUT NUMBER
, Y OUT NUMBER
) AS
BEGIN
SELECT X_COORD, Y_COORD INTO X,Y FROM MASTER_ADDRESS
WHERE HOUSE=HOUSE AND STR_NAME=STREET AND PRE_DIR IS NULL;
END GETADDRESSCOORDS;
When run, I receive this error msg:
SQL> execute getaddresscoords('1550', 'BEDFORD', :X, :Y)
BEGIN getaddresscoords('1550', 'BEDFORD', :X, :Y); END;
*
ERROR at line 1:
ORA-01422: exact fetch returns more than requested number of rows
ORA-06512: at "TAXLOTS.GETADDRESSCOORDS", line 9
ORA-06512: at line 1
So I got too many rows...but when I execute this:
SQL> SELECT MAX(rownum) from MASTER_ADDRESS where HOUSE='1550'
AND STR_NAME='BEDFORD' AND PRE_DIR IS NULL;
MAX(ROWNUM)
-----------
1
what am I missing here?
Your problem is related to variable scoping. In your SELECT statement, HOUSE will always refer to the column in the table, not to the parameter of the same name.
Generally, when writing PL/SQL, you use some sort of naming convention to differentiate parameters and local variables from columns in tables in order to make this more obvious. In your case, you probably want something like
create or replace
PROCEDURE GETADDRESSCOORDS
(
P_HOUSE IN VARCHAR2
, P_STREET IN VARCHAR2
, P_X OUT NUMBER
, P_Y OUT NUMBER
) AS
BEGIN
SELECT X_COORD, Y_COORD
INTO P_X,P_Y
FROM MASTER_ADDRESS
WHERE HOUSE=P_HOUSE
AND STR_NAME=P_STREET
AND PRE_DIR IS NULL;
END GETADDRESSCOORDS;
If you were to declare local variables, you would similarly use some sort of naming convention to differentiate them from columns in tables (i.e. l_local_variable).
You could explicitly specify the scope resolution for variables that match the names of columns as well but that tends to get much uglier (and you have to be very careful that you don't miss any situations where a column name and a variable name match and the scope resolution isn't explicitly specified). It would be legal to write
create or replace
PROCEDURE GETADDRESSCOORDS
(
HOUSE IN VARCHAR2
, STREET IN VARCHAR2
, X OUT NUMBER
, Y OUT NUMBER
) AS
BEGIN
SELECT X_COORD, Y_COORD
INTO X,Y
FROM MASTER_ADDRESS ma
WHERE ma.HOUSE=getAddressCoords.HOUSE
AND ma.STR_NAME=getAddressCoords.STREET
AND ma.PRE_DIR IS NULL;
END GETADDRESSCOORDS;
but this would not be very conventional.
I have a Stored Procedure like this
procedure P_IssueUpdate
(
Id in integer,
ModifiedDate in date,
Solution in varchar2
) AS
BEGIN
update T_Issue
Set
ModifiedDate = ModifiedDate,
Solution = Solution
where id = id;
END P_IssueUpdate;
my problem is that the parameter name is the same name as the Table column name.
Is there a way to instruct the sql that the value after the "=" should be the parameter and not the column?
Thanks for your help
You can prefix parameter and variable names with the name of the procedure like this:
SQL> declare
2 procedure p (empno number) is
3 ename varchar2(10);
4 begin
5 select ename
6 into p.ename
7 from emp
8 where empno = p.empno;
9 dbms_output.put_line(p.ename);
10 end;
11 begin
12 p (7839);
13 end;
14 /
KING
PL/SQL procedure successfully completed.
i found a solution. it's working by full qualifying the parameter:
procedure P_IssueUpdate
(
Id in integer,
ModifiedDate in date,
Solution in varchar2
) AS
BEGIN
update T_Issue
Set
ModifiedDate = P_IssueUpdate.ModifiedDate,
Solution = P_IssueUpdate.Solution
where id = P_IssueUpdate.id;
END P_IssueUpdate;
what you described is called variable shadowing. It can happen in any language. You were given good workarounds but the common solution is to design a naming scheme so that it will never happen.
For example, name your columns without prefix and have your variables with a prefix that depends upon their scope (P_ for parameters, L_ for local variables, G_ for global package variables, etc...). This will have the added benefit of making the code more readable by giving you additional information.
RE Vincent's answer about prepending a prefix--that solution works until somebody modifies the table and adds a column whose name happens to collide with the parameter name. Not everybody goes through every line of code to make sure their table modifications won't conflict with variable or parameter names. Oracle's recommendation is to qualify every parameter or variable name in a SQL query.
If you're working with an anonymous block (outside a procedure), you can name the block and qualify variables that way:
<<MY_BLOCK>>
declare
X sys.USER_TABLES%rowtype;
Y sys.USER_TABLES.TABLE_NAME%type := 'some_table_name';
begin
select UT.*
into MY_BLOCK.X
from sys.USER_TABLES UT
where UT.TABLE_NAME = MY_BLOCK.Y;
end MY_BLOCK;