I am trying to create the following procedure in oracle:
CREATE OR REPLACE PROCEDURE SPBILL (SPCLIENT_ID VARCHAR2)
AS
BEGIN
SELECT C.CLIENT_NAME, B.ROOM_ID, R.ROOM_COST, T.TREAT_NAME, T.TREAT_COST, (ROOM_COST*(B_END_DATE-B_START_DATE)+TREAT_COST) AS INVOICE
FROM CLIENTS C, ROOMS R, TREATMENTS T, BOOKING B, PRESCRIPTION P
WHERE C.CLIENT_ID=B.CLIENT_ID
AND R.ROOM_ID=B.ROOM_ID
AND B.CLIENT_ID=P.CLIENT_ID
AND P.TREAT_ID=T.TREAT_ID
AND C.CLIENT_ID=SPCLIENT_ID;
END SPBILL;
I am getting a "Procedure created with compilation errors" and the errors is PLS-00428, which required an INTO satement, but i do not understand why and where do i need it as my sql statement works just the way i want it without the procedure. But i need to create a procedure so i can call a specific client id and only recieve their data as an output.
When you are running the SQL directly using a client (SQL Plus or SQL Developer or Toad) , data is returned to the client.
When you run the same query inside PL/SQL, you need to tell oracle what to do with that data. Usually programs store the output in Pl/SQL variables for further processing.
https://docs.oracle.com/cd/B19306_01/appdev.102/b14261/selectinto_statement.htm
So, in your case, you might need something along these lines..
CREATE OR REPLACE PROCEDURE SPBILL (SPCLIENT_ID VARCHAR2)
AS
l_client_name clients.client_name%type;
l_room_id rooms.room_id%type;
...
l_invoice number(5,2);
BEGIN
SELECT C.CLIENT_NAME, B.ROOM_ID, R.ROOM_COST, T.TREAT_NAME, T.TREAT_COST, (ROOM_COST*(B_END_DATE-B_START_DATE)+TREAT_COST)
into l_client_name, l_room_id...l_invoice
FROM CLIENTS C, ROOMS R, TREATMENTS T, BOOKING B, PRESCRIPTION P
WHERE C.CLIENT_ID=B.CLIENT_ID
AND R.ROOM_ID=B.ROOM_ID
AND B.CLIENT_ID=P.CLIENT_ID
AND P.TREAT_ID=T.TREAT_ID
AND C.CLIENT_ID=SPCLIENT_ID;
--further processing here based on variables above.
dbms_output.put_line(l_invoice);
END SPBILL;
Once you compile without errors, you can run the procedure..
set serveroutput on;
SPBILL(100);
Maybe you should use IS instead of AS
CREATE OR REPLACE PROCEDURE SPBILL (SPCLIENT_ID VARCHAR2)
IS
....
It looks like you have experience with MSSQL and expect Oracle would be the same. If so, it isn't true.
It looks like you try to return resultset from procedure as it usual in MSSQL. Oracle have no implicit resultsets at all. If you wish to do this, you should use explicit resultset eighter via returning REF CURSOR (http://www.orafaq.com/wiki/REF_CURSOR) or via TABLE FUNCTION (https://docs.oracle.com/cd/B19306_01/appdev.102/b14289/dcitblfns.htm).
But first of all, you should think if you really need this procedure at all. Generally, SELECT procedures in Oracle is part of doubtful design.
Related
I have a requirement to return a subset of rows from a table using FOR UPDATE SKIP LOCKED. Based on application parameters this subset may or may not be ordered by a column. I can't use ROWNUM since the numbers are assigned before SKIP LOCKED happens, so using cursors and FETCH ... LIMIT seems to be the way to go.
That works using an anonymous PL/SQL block, but I need to expose the data back to the java application. The most straightforward way would be to use a table function, so I can just do SELECT * FROM table(my_function(<params>)).
I tried a standard table function returning a collection first, but I got the error [902] ORA-00902: invalid datatype. This is roughly what I had in place:
Package specification:
CREATE OR REPLACE PACKAGE ACTIVITY_UTILS AS
TYPE ActivityList IS TABLE OF ACTIVITY_TABLE%ROWTYPE;
FUNCTION activity_batch(batch_size IN INTEGER, order_by_source IN VARCHAR2)
RETURN ActivityList;
END ACTIVITY_UTILS;
Package body:
CREATE OR REPLACE PACKAGE BODY ACTIVITY_UTILS AS
FUNCTION activity_batch(batch_size IN INTEGER, order_by_source IN VARCHAR2)
RETURN ActivityList
IS
batch ActivityList := ActivityList();
selectStatement VARCHAR2(200);
TYPE CursorType IS REF CURSOR;
activitiesCursor CursorType;
BEGIN
IF UPPER(order_by_source) = 'TRUE' THEN
selectStatement := 'SELECT * FROM ACTIVITY_TABLE ORDER BY source FOR UPDATE SKIP LOCKED';
ELSE
selectStatement := 'SELECT * FROM ACTIVITY_TABLE FOR UPDATE SKIP LOCKED';
OPEN activitiesCursor FOR selectStatement;
FETCH activitiesCursor BULK COLLECT INTO batch LIMIT batch_size;
CLOSE activitiesCursor;
RETURN batch;
END activity_batch;
While debugging the ORA-00902 error I ran into this question:
Return collection from packaged function for use in select
My (limited) understanding was I was trying to use a PL/SQL type on plain SQL, which is not allowed. I tried using a pipelined table function, as mentioned in the answer, but then I got the error ORA-14551: cannot perform a DML operation inside a query.
This seemed odd, is SELECT ... FOR UPDATE considered DML? At any rate, I noticed I could workaround this by using pragma autonomous_transaction, but that defeats the purpose of having FOR UPDATE SKIP LOCKED.
My question is, is this requirement achievable at all using functions, or would I have to use a procedure with an OUT parameter?
Option 1: create a function (or procedure) that returns a cursor and let your java application fetch it normally.
Option 2: Use Implicit statement results: in this case your java application can run something like call proc() where proc returns implicit statement results.
PS. It's not a good idea to hide DML under SQL select...
I have been googling for a while to find an alternative approach for returning a resultset rather than returning a ref cursor but failed to find it so. As i have done most of my development in sql server where we won't use cursors unless until it is necessary but i understand it differs from ref. cursor. But on top of that when we return a ref. cursor as an output from database it will become a connected architecture. So my dear Geeks can you answer/clear my confusions as mentioned below,
I want to understand which is the better way for returning a result set to our application (Ref. cursor or SELECT statement with all the joins or any other options)?
Is using ref. cursor is a connected /disconnected architecture?
Is using Select sql query is better for a disconnected approach?
Thanks in advance.
As usual, it depends on your needs.
Regarding connected /disconnected architecture it makes almost no difference. After your client application received the RefCursor and all rows are fetched (and preferably the cursor is closed) you can disconnect and reconnect from database the same way as using direct SELECT statement.
Consider following pseudo-code examples:
SELECT EMP_NAME, DEPT_NAME
FROM EMP
JOIN DEPT ON EMP_DEPT_ID = DEPT_ID
WHERE DEPT_ID = :d;
vs.
CREATE FUNCTION GetEmps(deptId IN NUMBER) RETURN SYS_REFCURSOR IS
res SYS_REFCURSOR;
BEGIN
OPEN res FOR
SELECT EMP_NAME, DEPT_NAME
FROM EMP
JOIN DEPT ON EMP_DEPT_ID = DEPT_ID
WHERE DEPT_ID = deptId;
RETURN res;
END;
My personal favorite is to prefer a RefCursors because:
With RefCursor client and server are more separated from each other, i.e. the client just has to know the function name and which attributes he receives (EMP_NAMEand DEPT_NAME), nothing else. He does not have to know the table names or any join condition. Developers of client and server can work more independently from each other.
With RefCursor you can implement fine-granularity security methods. You only have to do grant execute on GetEmps to ... and the client gets EMP_NAME and DEPT_NAME - no more, no less!
With direct SELECT you have to grant select on both tables, however then the client could also execute SELECT SALARY, EMP_NAME FROM EMP; for instance (unless you use the quite expensive VPD feature from Oracle). If you like you can log every single call of the function and add as many constraints as you like.
with RefCursor the client application (and not the server) can decide how many rows he like to fetch in order to optimize response times.
the basic difference is that when you are uncertain about the sql query you are going to execute at run time, then use ref cursor and you can use same ref cursor for different sql queries. for example
for query
select name,id,dob from table where id=:v_id;
here v_id is passed at run time, so we can use ref cursor. v_id varies at run time.
While the select statement is used in for each loop when we have small set of records. When we have large set of records we can use bulk collect with ref cursor and limit rows.
In Oracle, all DML statements are cursors. A cursor is simply a set of instructions used by the optimizer to get to the data.
In my Oracle-centric opinion, everything that is done in the database should be done in stored procedures, so that you have a central interface into the database - ie. if you had two applications updating/retrieving data to/from the same database, you'd only need one set of stored procs on the database, rather than replicating the logic twice in each application.
With that in mind, ref cursors are the way to go.
However, if you're not going down that route (boo! *{;-) ) there is little difference between a ref cursor and a straight select statement in terms of getting the data to the front end. How you call for the data will be different, of course, but it's the same thing to the database.
All a ref cursor does is basically hold a pointer to a cursor.
I'm using SQL Oracle to build a stored procedure. I'm trying to build a stored procedure of the SQL-query below.And I want to return those data to a C# program.
select * from employee_master
I have tried following. Is this correct?
CREATE OR REPLACE PROCEDURE EMPLOYEE_SELECTALL (p_recordset OUTSYS_REFCURSOR)AS
BEGIN
OPEN p_recordset FOR
SELECT
*
FROM
EMPLOYEE_MASTER;
END EMPLOYEE_SELECTALL;
If you wish to build a stored procedure that return such resultset first of all you should check if you really need to do this. It's incidental and not recommended way for Oracle. But if you really need so, you should use REF CURSOR.
after executing your stored procedure in SQL Developer, it automatically brings back any output for you to view, including one or more ref cursors.
Example code and screenshots here
I'm used to Microsoft SQL Server, where the last SELECT query of a stored procedure determines what is returned.
In Oracle, I'm always using a SYS_REFCURSOR OUT parameter to return data from queries.
Are there other options of returning data from SELECT queries in Oracle stored procedures?
How about SELECT queries that select only one row? Is a SYS_REFCURSOR still necessary?
EDIT: I need to know the answer for Oracle 11g R2 (should have mentioned that explicitly instead of just in the tags).
Until now Oracle has not supported the SQL Server style of procedures implicitly returning a result set, you have had to explicitly return something - which could be a SYS_REFCURSOR or a collection or whatever.
In Oracle 12C a new feature has been added called Implicit Statement Results, which is designed to emulate the SQL Server way of working. However, this is really intended to support migration of existing code from SQL Server; for fresh Oracle development you would be best advised to learn the way Oracle normally does things.
Oracle PL/SQL Procedures can return all the supported basic datattype( date,varchar2,number) plus complex ( records, tables, varray)
Another option is the pipelined function, in which you call the function as:
select ...
from table(my_function(param1 => 1, ...))
See docs for details.
Just for clarifying, ORACLE procedures cannot 'RETURN" per se, a SYS_REFCURSOR OUT parameter is more like changing the value of a variable reference inside the procedure.
Apart from SYS_REFCURSOR, if you are returning only one row of a table, say EMPLOYEE, you can also define a record as EMPLOYEE%ROWTYPE and use it as a OUT type.
Or like:
PROCEDURE pr_proc (v_input in number
v_emp_row out EMPLOYEE%ROWTYPE )
IS
I have a stored procedure that I have defined in Oracle. In that procedure I need to return a recordset. To do this, I am using the SYS_REFCURSOR, which works great inside of Oracle (and with cx_Oracle, for that matter). In my application I am using SqlAlchemy scoped sessions, to support multi-threading.
How can I use the scoped session to return the REF CURSOR? The only way I have been able to get this to work is by declaring an out cursor with the cursor that is active in the session and then executing the stored procedure, like below:
sql = """
BEGIN
example('%s', '%s', '%s', :cur);
END;
""" % (cid, show, type)
conn = sa_tool.session.connection()
in_cur = conn._Connection__connection.cursor()
out_cur = conn._Connection__connection.cursor()
in_cur.execute(sql, cur=out_cur)
results = out_cur.fetchall()
Ideally, I would like to avoid using the connection object in this way, and execute the procedure while letting SqlAlchemy manage the cursors. If that is not possible, is there a reason that the fetch would take so long?
Thanks
I saw this question which was not answered and I decided to jump in. First of all, let me just say that for your scenario there is no better option than SYS_REFCURSOR. Of course, you have alternatives.
An Oracle Cursor is a memory area location where an instruction to execute a SQL statement is stored. A Ref cursor is just a pointer to the cursor location. SYS_REFCURSOR is an specific oracle defined typed of ref cursor. So when you return a SYS_REFCURSOR variable to a client, you are returning a pointer towards the memory location where the instruction to execute the SQL resides. Your client can now execute the instruction using the FETCH operation and get the rows. So this is the best possible way to return a result set to the client.
As an alternative, you might use a PIPELINED FUNCTION, but I can assure you that you won't get any better performance. AskTom has a great explanation about this comparison in this article
https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:9532870400346178516
Another scenario is whether you want to analyse where the time is consumed, either in the EXECUTE phase or in the FETCH one. If you have a huge time in FETCH, perhaps you might consider transfer the data in another way to the client. If you have a problem in EXECUTION, then you need to make a tuning exercise over your procedure.