Optional output cursor as parameter - oracle

I'm trying to cater for two applications.
One calls a procedure with 2 cursors, the other with 1.
Both are OUT SYS_REFCURSOR.
Because of the difference in definition of the procedure, the change to one application will break the other.
I am wondering if its possible to have the same procedure with both OUT SYS_REFCURSOR but with the second parameter as optional. This is done in other parts of the project by defining a default value.
I have tried googling and defining default values but to no avail. This doesnt seem to be a very common issue.
Is there a way to have this definition with an optional OUT SYS_REFCURSOR ?
Here is my code:
PROCEDURE Proc_GetQ (qList OUT SYS_REFCURSOR, qStack OUT SYS_REFCURSOR);
I would like qStack to be optional.
Thanks,
JFIT

What about method overloading?
PROCEDURE Proc_GetQ (qList OUT SYS_REFCURSOR, qStack OUT SYS_REFCURSOR);
PROCEDURE Proc_GetQ (qList OUT SYS_REFCURSOR);
Create a procedure with the same name, similar logic (better call 2-parameter version inside and pass only one outside), but only one OUT parameter.

Related

What does "IS" do in Oracle procedures?

I want to create a procedure in Oracle; however, any sample that I look on the internet, has an "IS" syntax, which I couldn't find any functionality for it.
CREATE [OR REPLACE] PROCEDURE procedure_name
[ (parameter [,parameter]) ]
IS
[declaration_section]
BEGIN
executable_section
[EXCEPTION
exception_section]
END [procedure_name];
Does anyone know what does "IS" do?
IS is part of Create procedure syntax: (can be replace with AS)
It separate the procedure definition from its contents.
The optional declaration section that follows allows you to declare local variables.
IS, in this context, tells us (and the compiler) that what follows is the body of the procedure. Its absence tells us (and the compiler) that it is merely a declaration (e.g. a forward declaration in a package body):
create or replace package body mypkg is
-- this is just a forward declaration for the procedure
procedure myproc (id in number);
-- this is the full definition of the procedure
procedure myproc (id in number)
IS
..body of myproc..;
end mypkg;
In the case of a schema-level procedure, we could (in theory) have a syntax that makes the IS optional since there is no need for forward declarations; but (thankfully) the designers of PL/SQL kept the syntax consistent with the in-package syntax so IS is still required anyway.

What to use for input parameter when debugging Oracle Stored Procedure using TOAD debugger

I inherited an awesome 600 line Stored Procedure in which I need to debug. I'm trying to debug by right clicking on the name of the stored procedure, clicking execute using sql debugger. This brings up a table in which I can manually enter my parameters. Great. Except one of the parameters is a OracleArray vArray INPUT parameter, and I'm not sure how to actually enter something like this as a parameter? I'm not familiar with Oracle.
Your question doesn't have a lot of details, so I'll have to give a vague answer. Here's how you can call a procedure (named other_procedure) which takes a VARRAY argument or other complicated setup. Once you've declared a test procedure, you can execute it with the debugger and then step into the procedure you actually care about.
CREATE OR REPLACE PROCEDURE test_procedure IS
-- (size and type of the varray should match the one in other_procedure)
TYPE my_array_t IS VARRAY(4) OF VARCHAR2(20);
-- define and initialize your array
test_array my_array_t := my_array_t('one','two','three');
BEGIN
-- call the procedure
other_procedure(test_array);
END;
/
If you're still having trouble, edit your question to provide more details (like the procedure definition and varray definition) and we can give a more specific answer.

Calling another PL/SQL procedure within a procedure

I'm new to PL/SQL & would greatly appreciate help in this. I've created a procedure to copy contracts. Now I want to call another procedure from within this procedure which shall copy all the programs related to the contract I'm copying. One contract can have multiple programs.
You cal call another procedure in another package by using PackageName.ProcedureName(vcParameters => 'InputParameter1'); If the procedure is in the same package you could do it without the PackageName, so just ProcedureName(vcParameters => 'InputParameter1');
You call a procedure by simply putting its name and parameters in your code, e.g.
begin
dbms_output.put_line('Demo');
end;
or within a procedure,
create or replace procedure demo
as
begin
dbms_output.put_line('Demo');
end;
I have used dbms_output.put_line as an example of a procedure, but obviously any other procedure would be called the same way:
begin
foo;
bar(1);
demo(true, 'Bananas', date '2018-01-01');
end;
For some reason, many beginners are tempted to add exec before the procedure call. I don't know where that comes from because PL/SQL has no such keyword. Possibly they are thinking of the SQL*Plus execute command, which can be abbreviated to exec. However, SQL*Plus is a separate command line utility with its own commands that have nothing to do with the PL/SQL language.

How do I pass a cursor value when calling a stored procedure?

This is only my second time diagnosing a PL/SQL procedure. I need to test the code in the stored procedure, and I'm trying to call it in SQL Developer. I have run the error details report, and the code has no obvious bugs in it.
So now I am trying to run it through a test window so I can see if the output is correct. However I can't seem to get the right argument for the 3 parameter. Here are the parameters in the the procedure.
CREATE OR REPLACE PROCEDURE ADVANCE.WW_DEATHDATE_REPORT(begindate varchar2, enddatevarchar2, RC1 IN OUT du_refCUR_PKG.RC) AS
Here is the Code I am trying to use to call the procedure. What do I need to do to get it to run correct? I keep getting error messages saying I'm using a wrong value in the parameter.
BEGIN
ADVANCE.WW_DEATHDATE_REPORT('20100101','20150101',du_refcur_pkg);
END;
There are multiple ways to do this, one way is like the below,
DECLARE
du_refcur_pkg SYS_REFCURSOR;
BEGIN
OPEN du_refcur_pkg FOR SELECT ... ;
ADVANCE.WW_DEATHDATE_REPORT('20100101','20150101',du_refcur_pkg);
END;
Another way would be,
BEGIN
ADVANCE.WW_DEATHDATE_REPORT( '20100101','20150101', CURSOR (SELECT ... ) );
END;

oracle plsql: retrieve runtime parameter values when you call a procedure

I need a generalized method to get list of runtime parameters (values) when I call a procedure. I need something similar to the $$PLSQL_UNIT that returns the name of the running procedure.
(plsql Oracle 10g)
E.g. look at this sample procedure:
(it simply prints its own name and parameters )
CREATE OR REPLACE PROCEDURE MY_PROC(ow in varchar2, tn IN varchar2)
IS
BEGIN
dbms_output.put_line('proc_name: '||$$PLSQL_UNIT||' parameters: '|| ow||' '||tn );
EXCEPTION
WHEN OTHERS THEN
DBMS_OUTPUT.PUT_LINE('ERRORE: ' ||SQLERRM);
END MY_PROC;
/
Running procedure produces the following output:
SQL>
1 BEGIN
2 IBAD_OWN.MY_PROC('first_par', 'second_par');
3 END;
4 /
proc_name: MY_PROC parameters: first_par second_par
PL/SQL procedure successfully completed.
I'm not satisfy because I can't copy and paste in all my procedures because I have to hard code each procedure to set their right parameter variables.
Thanks in advance for the help.
It isn't possible to dynamically retrieve the values of parameters passed to a procedure in Oracle PL/SQL. The language simply isn't designed to handle this kind of operation.
Incidentally, in a procedure that is located within a package, $$PLSQL_UNIT will only return the package's name. I find it's better to define a consistently-named constant within each procedure that contains the procedure's name.
When I wanted the same functionality as yours I didn't find any good built-in solution.
What I did is: wrote DB-level trigger which modifies original body of function/procedure/package.
This trigger adds immediatly after "begin" dynamically generated piece of code from "user_arguments".
Plus, after that I include into this trigger the code, that logs calls of procs when exception occures.
Plus, you can trace procs calls, and many more interisting things.
But this solution works fine only for preproduction because performance decreases dramatically.
PS. Sorry for my bad English.

Resources