Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Are PL/SQL stored procedures transactions?

Are PL/SQL stored procedures transactions? When a trigger, procedure or function runs, is it a transaction? I usually end my procedures with COMMIT and when an error occurs I use ROLLBACK! Is it wrong?

I'am not asking about START TRANSACTION into procedures but I want to know if they are transactions.

Thank you.

like image 435
Maghio Avatar asked Sep 19 '14 11:09

Maghio


People also ask

Are SQL stored procedures transactional?

Yes, a stored procedure can be run inside a transaction.

Do stored procedures run in a transaction?

There will only be one connection, it is what is used to run the procedure, no matter how many SQL commands within the stored procedure. since you have no explicit BEGIN TRANSACTION in the stored procedure, each statement will run on its own with no ability to rollback any changes if there is any error.

Is PL SQL same as stored procedure?

PL/SQL is a block-structured language that enables developers to combine the power of SQL with procedural statements. A stored procedure in PL/SQL is nothing but a series of declarative SQL statements which can be stored in the database catalogue. A procedure can be thought of as a function or a method.

What is the difference between stored procedure and transaction?

Return Values: Stored Procedures can return values but Triggers cannot return value. Transaction: Transaction statements such as begin transaction, commit transaction, and rollback inside a Stored Procedure. But, these statements cannot be used inside Trigger. Calling: Stored Procedure can be called inside a Trigger.


1 Answers

Are PL/SQL stored procedures transactions? When a trigger, procedure or function runs, is it a transaction?

No. A transaction starts with the first DML encountered and ends when it encounters a COMMIT or ROLLBACK. A transaction can comprise many function and procedure calls and DML statements and trigger code. On the other hand, you can create a procedure that comprises of many transactions by issuing lots of COMMITs.

I usually end my procedures with COMMIT and when an error occurs I use ROLLBACK! Is it wrong?

Wrong is a strong word. Let's just say it's not a good practice. Making (packaged) functions and procedures is all about modularization: making reusable pieces of code. When a function/procedure contains ROLLBACK or COMMIT statements, it stops being reusable as it messes up the transaction of the caller. So it's better not to use ROLLBACK or COMMIT in your procedures and leave it to the topmost caller.

You could use SAVEPOINTS throughout your code which makes sure a single function or procedure doesn't leave open parts of a transaction. But for esthetical reasons I prefer to not use SAVEPOINTS. For me, it's just five lines of unnecessary code, because I know my caller function will handle the transaction just nicely.

Exception is when you create an autonomous procedure, which is by definition a single transaction and thus needs to end with a COMMIT.

UPDATE

Note that a RAISE_APPLICATION_ERROR or a RAISE [exception name] statement will also automatically rollback your PL/SQL block as a single atomic unit. Which is of course a desirable effect as it doesn't leave you with uncommitted changes.

SQL> create table mytable (id int)
  2  /

Table created.

SQL> create procedure p
  2  as
  3  begin
  4    insert into mytable values (2);
  5    raise_application_error(-20000,'My exception');
  6  end;
  7  /

Procedure created.

SQL> select *
  2    from mytable
  3  /

no rows selected

SQL> insert into mytable values (1)
  2  /

1 row created.

SQL> exec p
BEGIN p; END;

*
ERROR at line 1:
ORA-20000: My exception
ORA-06512: in "X.P", regel 5
ORA-06512: in regel 1


SQL> select *
  2    from mytable
  3  /

        ID
----------
         1

1 row selected.
like image 172
Rob van Wijk Avatar answered Oct 03 '22 20:10

Rob van Wijk