Do I need to issue commit command after running the stored function with select query?
Yes, you do, in some cases (please read the discussion in the link below). The rule is: Always commit if you made change in DB (after DML commands), even with SELECT statement.
Use the COMMIT statement to end your current transaction and make permanent all changes performed in the transaction.
Read more: oracle - what statements need to be committed?
Thanks #Ben for the head up!
commit means "save the changes"
select statement does not change any data.
changing data can be done by Insert, update, delete statements (Data Manipulation language) .
You need to commit an sql statement only if you have performed a DML statement (INSERT, DELETE, UPDATE, MERGE) in your stored procedure. So, if you only queried the data, there is no need to commit.
Related
please I want to understand the difference between the folowing two statements:
insert into table_name values (,,,,,);
and
insert into table_name values (,,,,,);
commit;
If you insert data without commit you can select data from database and see it. But other users can't.
It's better to look to sql documentation:
Until you commit a transaction:
You can see any changes you have made during the transaction by
querying the modified tables, but other users cannot see the changes.
After you commit the transaction, the changes are visible to other
users' statements that execute after the commit.
You can roll back (undo) any changes made during the transaction with
the ROLLBACK statement (see ROLLBACK.
for example here Oracle Documentation
and some info about transactions
All the DML (insert, update , delete) to be inserted in the database you have to commit them, like approve that you want to add them in the database. If you dont commit DML statment , it will not be enter in the database.
what is commit ?
Docs.oracle cant describe it better
Use the COMMIT statement to end your current transaction and make
permanent all changes performed in the transaction. A transaction is a
sequence of SQL statements that Oracle Database treats as a single
unit. his statement also erases all savepoints in the transaction and
releases transaction locks.
I have read the explanations when a commit may be neccessary after a select statement for DB2 and MySQL:
Is a commit needed on a select query in DB2?
Should I commit after a single select
My question is when and why would it be important to commit after executing a select statement using Oracle?
If you did a SELECT ... FOR UPDATE; you would need a COMMIT or ROLLBACK to release the records held for update. Otherwise, I can't think of any reason to do this.
there are only a few situations that I can think of that you may want to commit after a select.
if your select is joining on database links, a transaction will be created. if you attempt to close this link, you'd get an error unless you committed/rolled back the transaction.
select for update (as DCookie says) to release the locks.
to remove an serialized isolation level if set or to add one, if you've been selecting from db links prior to invoking this.
I know that in MySQL ddl statements such as alter table/create table/etc cause an implicit transaction commit.
As we are moving to PostgreSQL is it possible to wrap multiple DDL statments in a transaction?
This would make migration scripts a lot more robust, a failed DDL change would cause everything to rollback.
DDL statements are covered by transactions. I can't find the relevant section in the official documentation, but have provided a link to the wiki which covers it.
Just remember that transactions aren't automatically opened in postgresql, you must start them with BEGIN or START TRANSACTION.
Postgresql Wiki about Transactional DDL
Not every Postgres DDL statement can be wrapped in transaction. Statements like DROP DATABASE / DROP TABLESPACE and some other file-system-related cant rollback.
Also:
ALTER TYPE ... ADD VALUE (the form that adds a new value to an enum
type) cannot be executed inside a transaction block.
Also some statements like TRUNCATE are 'not MVCC save'. Changes, made by that kind of statements can affect other queries, even if they are rolled back.
So - read the official manual for your version of postgres to find out if your DDL's are transaction safe.
I have a BEFORE DELETE trigger which inserts rows into another table using SPI_exec.
Do these INSERT queries run in the same transaction as the one in which the original delete is executing? Hence, will the delete and all inserts roll back or commit together?
If not, how can I make that happen?
Yes, everything in triggers is in the same transaction as the triggering event.
Not directly related to the question, but normally you want to put side-effects in the AFTER trigger, rather than the BEFORE trigger.
Is Commit a DML instruction in PL\SQL?
No, it's a transaction control (TCL) statement, not a data manipulation (DML) statement. Here is a list of SQL statement types.
No COMMIT is not a DML instruction. It comes under TCL. COMMIT is used to save the changes made by using DML instructions. In general COMMIT is used with ROLLBACK.
DML:
Data manipulation language (DML) statements access and manipulate data in existing schema objects. These statements do not implicitly commit the current transaction.
CALL
DELETE
EXPLAIN
PLAN
INSERT
LOCK
TABLE
MERGE
SELECT
UPDATE
The SELECT statement is a limited form of DML statement in that it can only access data in the database. It cannot manipulate data in the database, although it can operate on the accessed data before returning the results of the query.
The CALL and EXPLAIN PLAN statements are supported in PL/SQL only when executed dynamically. All other DML statements are fully supported in PL/SQL
TCL:
Transaction control statements manage changes made by DML statements
COMMIT
ROLLBACK
SAVEPOINT
SET TRANSACTION