I have been having this question for while now
we can Implement a cursor for Example
SET serveroutput ON;
DECLARE
CURSOR test_cursor
IS
SELECT * FROM employees;
BEGIN
FOR i IN test_cursor
LOOP
DBMS_OUTPUT.PUT_LINE(i.employee_id||' '||i.First_name);
END LOOP;
END;
Also we can implement the same in below way
SET serveroutput ON;
BEGIN
FOR rec IN
(SELECT * FROM employees
)
LOOP
DBMS_OUTPUT.PUT_LINE(rec.employee_id ||' ' ||rec.First_name);
END LOOP;
END;
Why do we need a cursor here then? Please could you let me know the differences and its advantages/disadvantages?
In both cases, you actually use cursors.
The first one is declared and named (explicit).
The second one is anonymous (implicit).
http://docs.oracle.com/cd/B10501_01/appdev.920/a96624/01_oview.htm#740.
I usually use explicit cursors for better code readability and in cases, when I want to reuse the cursor, I can fetch the data from result cache or fetch the data into variable and iterate through an array.
Also, as far as I know, execution plan is not generated as often as while using the implicit cursor (the DB searches for the query in SGA by query's hash and can find already stored execution plan, thus skips the execution plan generation).
https://docs.oracle.com/database/121/TGSQL/tgsql_sqlproc.htm#TGSQL175
So firstly, these are both known as cursor FOR LOOPs.
http://docs.oracle.com/database/121/LNPLS/cursor_for_loop_statement.htm#LNPLS1143
One usability difference between the two forms is that the second form places the SQL that is executing directly before the code in which the result set is used. This can make it easier to understand the code.
One useful syntax difference is that in the first form you can pass parameters into the cursor to modify its behaviour (see above link for syntax). So if you use the same basic cursor definition multiple times, but with different parameters to pass in, then use the former.
Related
UPDATE - I have figured out how to add the stored procedures using code-first migration. 'All' I am wondering now is how I can apply a SELECT * FROM _tempTable1_ UNION SELECT * FROM _tempTable2, and then output this. I was thinking of implementing a third stored procedure which does this but I am not sure whether this is the right thing to do? Much appreciated help:)
I have a table connected to my ASP.NET MVC application, and I have created two stored procedures in SQL Server. Is it possible to implement these stored procedures in a way so that when the table is output, it can be grouped into these stored procedures?
MetBasicCriteria
ALTER PROCEDURE [dbo].[MetBasicCriteria]
-- Add the parameters for the stored procedure here
AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
-- Insert statements for procedure here
SELECT *
FROM dbo.Applications
WHERE NorwegianCitizen=1
AND CurrentlyInUni=1
AND Norwegian=1
AND English=1
END
MetMoreCriteria
ALTER PROCEDURE [dbo].[MetMoreCriteria]
-- Add the parameters for the stored procedure here
AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
-- Insert statements for procedure here
--EXEC [dbo.MetBasicCriteria]
SELECT *
FROM dbo.Applications
WHERE (Dutch=1
OR OtherCitizenships='Dutch'
OR (Course_bachelor='Political Science' OR Course_bachelor='Economy' OR Course_bachelor='International Relations')
OR (Grade_Bachelor='a' OR Grade_Bachelor='A' OR Grade_Bachelor='b' OR Grade_Bachelor='B'))
--AND MetBasicCriteria=1
END
In other words --> can I use say 3 different stored procedures, save the outcomes of these 3 into different temporary tables, and the using UNION ALL combine them into 1 temporary table?
Thanks in advance
I just take your second procedure code and modify it as a simple POC. I have no idea how you intend to merge or alter or combine the resultsets from your first procedure with that of your second procedure. So I leave that for you. I will also remove the meaningless comments you leave in the code since you seem to be using some sort of template.
ALTER PROCEDURE [dbo].[MetMoreCriteria]
AS
BEGIN
SET NOCOUNT ON;
create table #basic (
id int not null,
...
);
Insert #basic (id) --column list to be defined
EXEC [dbo.MetBasicCriteria];
SELECT appl.id, ...
FROM dbo.Applications as appl
WHERE (appl.Dutch=1
OR appl.OtherCitizenships='Dutch'
OR (appl.Course_bachelor in ('Political Science', 'Economy', 'International Relations'))
OR (appl.Grade_Bachelor in ('A', 'a', 'B', 'b'))
)
AND EXISTS (SELECT * FROM #basic as basic where basic.id = appl.id)
ORDER BY ...;
END
Hopefully I used the parentheses correctly but I can't test it and this edit widget does not auto-count or correct typos or mistakes. Some better coding points:
define an alias for each table and use it for every column reference.
don't use "*" generally as a column list
Using IN rather than a series of logical OR comparisons makes your code more readable and less prone to error
The column list in the SELECT and INSERT statements should be specific - don't use the lazy asterisk to select all columns since you typically don't need them all. If you do need them all, then specify each column to avoid future problems if the schema of the tables changes. The only place where "*" is acceptable as a column list is inside an EXISTS clause.
I also added the ORDER BY clause since the consumer of a resultset usually wants those rows ordered. But perhaps your application/consumer does not care? If so, remove it and save some processor cycles.
Lastly this is just one approach. You could also make your first procedure a view or a UDF since it does nothing complicated. And that comment can also apply to this procedure. Perhaps you are just over-complicating a rather simple set of logic? NB that I omit any error-handling and leave that to you. And let me re-iterate that this is NOT a recommendation. Simply one implementation option.
i am trying to find out at what age an employee started working.
if he started under 16 he should report this 'Error when entering the date of birth' mistake. so my trigger is created but my trigger is not working
I get ever this error: ORA-01422: Exact retrieval returns more than the requested number of lines
i can't find the problem
Here is the code:
SET SERVEROUTPUT ON
ACCEPT Birthday PROMPT ' Pleas give you Date of birth: '
CREATE OR REPLACE TRIGGER T_Controll
before INSERT ON meine_Firma -- Table
FOR EACH ROW
DECLARE
V_Berufstart meine_Firma.Hiredate%TYPE; --Job begin
V_Geburtsdatum DATE; -- Date of birth
V_Alter number:=0; -- AGE
SELECT HIREDATE INTO V_Berufstart FROM meine_Firma;
BEGIN
V_Geburtsdatum:=('&Birthday');
V_Alter:= Round(MONTHS_BETWEEN(V_Berufstart,V_Geburtsdatum)-2)/12;
IF 16 > V_Alter THEN
RAISE_APPLICATION_ERROR(-20201,'Error when entering the date of birth');
END IF;
END;
/
SET SERVEROUTPUT OFF
If he under 16 then he may not work
sorry my english is not good (=
You have a much bigger issue in this script than the error you are getting. Even after correcting as #ShaunPeterson suggested it will still fail
, it WILL NOT generate an error it will just not run as you expect. The issue is you failed to understand substitution variables - the use of &name (Specifically here &Birthday.) I'll actually use &Birthday in the following but the discussion applies to ANY/ALL substitution variables.
people fail to understand why they can't use the "&" substitution
variables in their PL/SQL procedures and functions to prompt for input
at run time. This article will hopefully help clarify in your mind
what the differences are so that you can understand where and when to
use these.
Substitution Variables The clue here is in the name... "substitution". It relates to values being substituted into the code
before it is submitted to the database. These substitutions are
carried out by the interface being used
The effect of this substitution is the the line containing the substitution variable is physically rewritten by the interface replacing %Birthday. In this case if you don't enter a value or the date 2000-05-19 the statement before and after substitution is
BEFORE: V_Geburtsdatum:=('&Birthday');
AFTER: V_Geburtsdatum:=(''); OR V_Geburtsdatum:=('2000-05-19');
Either way the after is what the compiler sees; it does NOT see %Birthday at all. Moreover when run the trigger will not prompt for a value. As far as the compiler is concerned it is a hard coded value that will never change. Beyond that a trigger, or any other PLSQL script (stored or anonymous) never prompts for values, they are actually incapable of doing so as it is not part of the language. Any prompt is via your interface software not plsql.
I'm going to suggest a way to avoid the trigger altogether. Getting on soap box: Triggers are BAD, they have some usefulness for assigning auto incrementing keys (before 12c),logging, very limited auditing, etc. However, for business rules they should be the option of last resort. Ok Get off soap box.
The first thing is to make the columns meine_Firma.Hiredate and meine_Firma.Geburtsdatum NOT null (if not already). If either are NULL you cannot calculate anything with them, the result would be NULL.
Second create a new column age_at_hire (or whatever) as a virtual column then put a check constraint on it. And voila trigger no longer needed. See fiddle for demo.
So the proposed change (YES you will probably have to clean up the bad data first):
alter table meine_Firma modify
( hiredate not null
, Geburtsdatum not null
) ;
alter table meine_Firma add
( age_at_hire integer generated always as (trunc(months_between(hiredate,Geburtsdatum))) virtual
, constraint check_age_at_hire check (age_at_hire >= 16*12)
);
Anyway, I hope you get an understanding of substitution variables for the future. And learn to avoid triggers. Good luck.
The reason you are getting that specific error is that the below select will select ALL rows from meine_Firma as there is no where clause
SELECT HIREDATE INTO V_Berufstart FROM meine_Firma;
However because you are in a trigger you do not need to select anything you use the :NEW bind variable. So you can just use
V_Berufstart := :NEW.HIREDATE;
If this was an update trigger there would be both a :NEW and :OLD bind variable declared so that you can access the OLD and NEW values. As this is an Insert trigger the :OLD will just be null as there is no old values.
I have been asked to create an SP which creates temporary table and insert some records.
I am preparing some sample code for the same as mentioned below but the output is not displayed.
create or replace procedure Test
is
stmt varchar2(1000);
stmt2 varchar2(1000);
begin
stmt := 'create global temporary table temp_1(id number(10))';
execute immediate stmt;
insert into temp_1(id) values (10);
execute immediate 'Select * from temp_1';
execute immediate 'Drop table temp_1';
commit;
end;
When i am executing the SP by (Exec Test) desired O/P is not displayed.
I am expecting O/P of "Select * from temp_1" to be displayed. But it is not happening. Please suggest where i am doing wrong.
But i am interesting in knowing why ( execute immediate 'Select * from temp_1';) do not yield any result
For two reasons. Firstly because as #a_horse_with_no_name said PL/SQL won't display the result of a query. But more importantly here, perhaps, the query is never actually executed. This behaviour is stated in the documentation:
If dynamic_sql_statement is a SELECT statement, and you omit both into_clause and bulk_collect_into_clause, then *execute_immediate_statement( never executes.
You would have to execute immediate into a variable, or more likely a collection if your real scenario has more than one row, and then process that data - iterating over the collection in the bulk case.
There is not really a reliable way to display anything from PL/SQL; you can use dbms_output but that's more suited for debugging than real output, and you usually have no guarantee that the client will be configured to show whatever you put into its buffer.
This is all rather academic since creating and dropping a GTT on the fly is not a good idea and there are better ways to accomplish whatever it is you're trying to do.
The block you showed shouldn't actually run at all; as you're creating temp_1 dynamically, the static SQL insert into temp_1 will error as that table does not yet exist when the block is compiled. The insert would have to be dynamic too. Any dynamic SQL is a bit of a warning sign you're maybe doing something wrong, though it is sometimes necessary; having to do everything dynamically suggests the whole approach needs a rethink, as does creating objects at runtime.
How to define FOR LOOP without Cursor in Teradata?
Actually I'm having code like this:
CREATE PROCEDURE TEST1()
BEGIN
DECLARE VAR1 VARCAHR(200);
DECLARE VAR2 VARCAHR(200);
FOR FOR_LOOP1 AS CUR_NAME CURSOR FOR
DO
---------SQL STATEMENT-------
FOR FOR_LOOP2 AS CUR_NAME1 CURSOR FOR
DO
---------SQL STATEMENT-------
END FOR;
END FOR;
END;
I need to execute NESTED CURSOR or FOR LOOP in Teradata, by taking the output of first cursor value, I need do execute the second cursor.
Can any one guide me, please!
Looks like you worked on Oracle before :-)
Although this is possible in Teradata using exactly the syntax you provided it's not recommended as cursors are sequential by nature while Teradata is a parallel DBMS. Cursors are already evil, but nested cursors are even worse.
Most cursors processing data can be rewritten, e.g. using Windowed Aggregate Functions (best case), have a look at George Coleman's blog
Can you provide the actual code?
I would like to ask you how would you increase the performance on Insert cursor in this code?
I need to use dynamic plsql to fetch data but dont know how to improve the INSERT in best way. like Bulk Insert maybe?
Please let me know with code example if possible.
// This is how i use cur_handle:
cur_HANDLE integer;
cur_HANDLE := dbms_sql.open_cursor;
DBMS_SQL.PARSE(cur_HANDLE, W_STMT, DBMS_SQL.NATIVE);
DBMS_SQL.DESCRIBE_COLUMNS2(cur_HANDLE, W_NO_OF_COLS, W_DESC_TAB);
LOOP
-- Fetch a row
IF DBMS_SQL.FETCH_ROWS(cur_HANDLE) > 0 THEN
DBMS_SQL.column_value(cur_HANDLE, 9, cont_ID);
DBMS_SQL.COLUMN_VALUE(cur_HANDLE, 3, proj_NR);
ELSE
EXIT;
END IF;
Insert into w_Contracts values(counter, cont_ID, proj_NR);
counter := counter + 1;
END LOOP;
You should do database actions in sets whenever possible, rather than row-by-row inserts. You don't tell us what CUR_HANDLE is, so I can't really rewrite this, but you should probably do something like:
INSERT INTO w_contracts
SELECT ROWNUM, cont_id, proj_nr
FROM ( ... some table or joined tables or whatever... )
Though if your first value there is a primary key, it would probably be better to assign it from a sequence.
Solution 1) You can populate inside the loop a PL/SQL array and then just after the loop insert the whole array in one step using:
FORALL i in contracts_tab.first .. contracts_tab.last
INSERT INTO w_contracts VALUES contracts_tab(i);
Solution 2) if the v_stmt contains a valid SQL statement you can directly insert data into the table using
EXECUTE IMMEDIATE 'INSERT INTO w_contracts (counter, cont_id, proj_nr)
SELECT rownum, 9, 3 FROM ('||v_stmt||')';
"select statement is assembled from a website, ex if user choose to
include more detailed search then the select statement is changed and
the result looks different in the end. The whole application is a web
site build on dinamic plsql code."
This is a dangerous proposition, because it opens your database to SQL injection. This is the scenario in which Bad People subvert your parameters to expand the data they can retrieve or to escalate privileges. At the very least you need to be using DBMS_ASSERT to validate user input. Find out more.
Of course, if you are allowing users to pass whole SQL strings (you haven't provided any information regarding the construction of W_STMT) then all bets are off. DBMS_ASSERT won't help you there.
Anyway, as you have failed to give the additional information we actually need, please let me spell it out for you:
will the SELECT statement always have the same column names from the same table name, or can the user change those two?
will you always be interested in the third and ninth columns?
how is the W_STMT string assembled? How much control do you have over its projection?