I'm a bit confused by the stored procedure syntax in Oracle.
I started with a simple:
select * from test_table;
It works, then I put it in a proc:
CREATE OR REPLACE PROCEDURE example
IS
BEGIN
select * from test_table;
END;
Doesn't work. Expected "INTO" is the error message I get. Now, I've seen syntax examples of SQL Server code that just shoves a select statement into a proc and it works instantly, but that doesn't seem to be the case here.
T-SQL and PL/SQL are completely different languages. In particular, for PL/SQL you have to select the result into some variable or cursor. Depending on what you plan to do with the record data - process in the procedure - or return to the caller, will drive what you have to do.
In your example, if you want to return the record set, you would do something like this:
CREATE OR REPLACE PROCEDURE example (
p_recordset OUT SYS_REFCURSOR) AS
BEGIN
OPEN p_recordset FOR
select * from test_table;
END example ;
See this link for examples.
Hello and welcome to SO.
I assume the full error you're seeing would be PLS-00428: an INTO clause is expected in this SELECT statement and it is correct, you must have an INTO statement in a stored procedure.
I recommend this link for syntax relating to the SELECT INTO statement.
For your code I recommend this (I've changed from your test_table example to dba_user):
CREATE OR REPLACE PROCEDURE example
IS
l_username VARCHAR(25);
BEGIN
select username INTO l_username from dba_users where user_id=1;
END;
/
Note: The INTO clause works with 1 column from 1 row. You cannot select multiple records or columns into this. You would need to reference the BULK COLLECT feature to do that. For examples of that feel free to read here.
select * from test_table;
SQL and PL/SQL are nor the same. To execute a SQL in a procedure, the parser expects an INTO clause to store the value returned by the sql statement. In PL/SQL, there is a reason to execute a SQL statement. You want to use the result set later to process. Not just retrieve and do nothing.
Also, it is a bad idea to use select * in any production system. You don't want to dump all the columns data of the table on an application screen. There are many other reasons, however, not in the scope of this question.
You need to modify your SQL like following -
SELECT column_name INTO variable FROM table_name
There are several ways to fetch the data via SQL statement in PL/SQL. You need to elaborate your requirement and narrow down to specific steps here.
If you are learning about these concepts, I would recommend you to start reading the Oracle documentation first. Try and understand the concepts, and if you find any issues, then prepare a test case, explain your issue in words and then post a question. Too broad questions are difficult to answer, and are mostly considered out of scope.
Related
In SQL Developer,
I want to call a script like this:
#"path\to\script.sql" develop
and use the value develop in my script as a table prefix like this:
SELECT * FROM <parameter>_table; which should then evaluate to SELECT * FROM develop_table
Is something like this possible in SQL Developer?
See the article below. It will answer your question.
https://blogs.oracle.com/opal/sqlplus-101-substitution-variables#2_7
I'll make an example for you, based off that blog article.
Creating a dummy table:
CREATE TABLE t(x NUMBER, t VARCHAR2(255));
INSERT INTO t(x, t) VALUES (1, 'Example');
COMMIT;
The script below has been saved in C:\Users\William. The filename is example.sql.
SELECT *
FROM &1
;
Now, from SQL Developer, I execute:
#C:\Users\William\example.sql t
Note that when you pass a parameter to a script like this, you are passing the text value that is stored in implicitly-named substitution variables. The substitution variable is named according to its order (e.g., &1 then &2 then &3 etc.).
This is the script output:
old:SELECT *
FROM &1
new:SELECT *
FROM t
X T
-- ----------
1 Example
You should probably take some time to consider other solutions to the problem you are solving. You may not need to execute a script via SQL developer. Perhaps you'd be better off creating a procedure that generates dynamic SQL, based off parameters you feed to the procedure. You would then use EXECUTE IMMEDIATE on the dynamic SQL statement inside the procedure.
I personally might find that technique more useful when performing actions like ETL (as opposed to queries). Then again, I'm no expert, and there're probably even better solutions out there.
I know we can call the function from SQL if it doesn't contain out parameter or DML(except autonomous). But we can't call the procedure from SQL in any condition.
What is the reason for it?
Why can't we call the procedure from SQL? Any specific reason.
The reason is that the SQL ANSII standard specifies that only functions can be used in the SQL query.
ISO committee members did not define the use of procedures in SQL queries.
You can:
call dbms_output.put_line('Hello')
CALL is part of the SQL language.
Or we can embed a procedure in an inline function:
with function f (p varchar2)
return varchar2
as
begin
dbms_output.put_line('Hello');
return p;
end f;
select f('Demo')
from dual
If you mean a SELECT statement specifically, I can't see how you expect that to work. What result set would you expect a query like this to return?
select dbms_output.put_line('Hello')
from dual
or
select dbms_stats.gather_table_stats(user, table_name)
from user_tables
This isn't an arbitrary restriction by some standards committee. It just doesn't make any sense semantically.
You can call or execute a procedure easily in SQL. Both parametrized or non can be called.
EXEC dbo.procedure_name
I'm assuming, that you are asking about calling procedures from within other SQL statements (not just call a procedure on its own, which is obviously possible).
Why? That's a matter of opinion, and you would have to ask Oracle DB architects for a real cause.
It would seem, that introducing procedure calls into all possible SQL statements, would bring both syntax and implementation complexity, while not necessarily bringing much more value. Usually there are alternatives, which are not much harder to use, while allowing the same outcome.
In case of a query (a SELECT statement), the result should be a data set, and no changes in the database state (data or structure) should be done. A PL/SQL procedure does not return a data set, and can change the database state.
If you are in a situation, where the procedure call is needed to prepare the data, you'd like to query, then you have the possibility to call the procedure first, and then query the database.
You can also write a procedure, which will have an output parameter of a cursor reference, which will effectively give you a query result. (For an ad hoc case, you could use parameterized anonymous PL/SQL block.)
You can also write a tabular function, where you can do complex data processing, using PL/SQL, and return a data set. Such function can be used in a query.
If you are asking also about other types of SQL statements, then you can always call DML (INSERT / UPDATE / DELETE / MERGE), DDL (CREATE / ALTER / DROP) or DCL (GRANT / REVOKE) from a procedure or an anonymous PL/SQ block, that does those and allows you to mix PL/SQL logic in. No need to do this the other way (introducing PL/SQL into DML / DDL / DCL).
I have a store procedure that takes in a uniqueidentifier and returns a table. What I am trying to do is to use these results like a regular table, but I realize SQL is still limited and doesn't allow it (yet!)
Example:
SELECT *
FROM MyTable MT
WHERE NOT EXISTS
(SELECT *
FROM MyStoredProc(MT.ID) MSP
WHERE MT.SomeData = MSP.SomeData)
Is there an alternative solution to this problem? And please don't suggest using a function or a view as they are not exchangeable with a stored procedure. I'm actually quite surprised that the developers haven't implemented this yet considering the age of SQL.
Any help would be really appreciated!
That syntax won't work. You'd have to dump the results of the stored proc into a temp table and the reference the temp table.
Because Of the parameter, I'd suggest either making a new version of the proc that can execute for all IDs at once or drop the proc code into a table valued function (which can be executed using the syntax you're trying to use).
I'm writing a pretty basic stored procedure that just takes values from the sample DB2 database and computes the standard deviation. I wrote the procedure itself just fine, and I can call it without error. But I can't figure out how to actually display my result or select it in a statement. Everything I try results in a syntax error and I haven't been able to find anyone doing this specific task in my google searches.
This is the gist of my code (snipped for brevity):
CREATE PROCEDURE SAL_STD_DEV
(OUT std_dev real)
LANGUAGE SQL
BEGIN
--do stuff
SET std_dev = 10; --changed for simplicity
END#
CALL SAL_STD_DEV(?)#
All this runs, but just CALL doesn't create any output. What's the syntax to SELECT the out variable? I can't put a DECLARE before the CALL because it's not in a stored procedure, and PRINT doesn't work either.
(# is my terminal character because I'm using ; in the stored procedure)
Edit: Both the create procedure and call statements are made in the same SQL file, the database is connect to through localhost and I'm using DB2 11.1.0.1527 and developing in IBM Data Studio 4.1.2.
From wherever the CALL is being made, that feature might present a Result Set, despite apparently not presenting the result of an OUT parameter. If so, then the stored procedure perhaps could be revised to return the OUT value [instead, or additionally] as a result set, so that the interface that accepts the CALL statement as input, might present that result-set. Regardless:
In a statement processor [e.g. that is not a GUI, but] for which SELECT query output is presented, the following scripted requests should likely suffice:
create variable my_real real
;
call SAL_STD_DEV(my_real)
;
select my_real from sysibm.sysdummy1
;
I have an SQL statement in Oracle SQL developer that has some variables:
DEFINE custom_date = "'22-JUL-2016'" --run1
DEFINE custom_date = "'25-JUL-2016'" --run2
SELECT * FROM TABLE WHERE date=&custom_date
The real query is much more complicated and has many more variables and new tables are created from the results of the query. How can I create a script so that the query is executed twice, the first time with the custom date set as in the first line and the second time as in the second line.
In Oracle, the &variable is a "substitution variable" and is not part of SQL; it is part of the SQL*Plus scripting language (understood by SQL Developer, Toad etc.)
The better option, and what you are asking about, is BIND VARIABLES. The notation is :variable (with a colon : instead of &), for example :custom_date.
The difference is that a substitution variable is replaced by its value in the front-end application (SQL Developer in your case) before the query is ever sent to the Oracle engine proper. A bind variable is substituted at runtime. This has several benefits; discussing them is outside the scope of your question.
When you execute a query with bind variables in SQL Developer, the program will open a window where you enter the desired values for the bind variables. You will have to experiment with that a little bit till you can make it work (for example I never remember if a date must be entered with the single quotes or without). Good luck!
Define is used in TRANSACT SQL. To do this Oracle way, You can create anonymus PL/SQL block, similar to this:
DECLARE
p_param1 DATE;
p_param2 NUMBER;
CURSOR c_cur1(cp_param1 DATE,cp_param2 NUMBER)
IS
SELECT * FROM table WHERE date = cp_param1
;
BEGIN
-- Execute it first time
p_param1 := TO_DATE('2016-09-01','YYYY-MM-DD');
FOR r IN c_cur1(p_param1)
LOOP
NULL;
END LOOP;
-- Execute it second time
p_param1 := TO_DATE('2015-10-11','YYYY-MM-DD');
FOR r IN c_cur1(p_param1)
LOOP
NULL;
END LOOP;
END;
And in it, You create cursor with parameters and execute it twice with different parameter.
I do not know why You want to execute this query twice, so the script abowe does nothing with results, but it certainly should execute Your query twice, with different params.