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.
Related
Let's say a table has a validation trigger that enforces some business logic:
TRG_MYTABLE_INSERT_UPDATE_VALIDATION
FOR INSERT, UPDATE on MYTABLE
and an audit trigger that writes all inserts and updates to another table.
TRG_MYTABLE_INSERT_UPDATE_AUDIT
FOR INSERT, UPDATE on MYTABLE
and there's no guarantee that they will be executed in a particular order, will a rollback in the VALIDATION trigger rollback the write to the audit table?
Are all of the triggers enlisted in the same transaction "behind the scenes"?
To answer the question about triggers and transactions: yes triggers are enlisted in the same explicit, or implicit, transaction as the code that executes the statement which makes the trigger fire is enlisted in.
Furthermore, in SQL Server triggers runs be default under XACT_ABORT ON which means that if an error happens in the trigger, the WHOLE transaction is rolled back immediately.
So the answer to your question is that if an error happens in either of the triggers, the whole transaction is rolled back.
You can however do a SET XACT_ABORT OFF in your transaction code, in which case, a rollback would only impact whatever you do in the trigger. That is UNLESS your calling code starts a transaction, and you explicitly do a ROLLBACK in your trigger.
The above is why you should be very careful with using triggers in the first place.
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.
I heard in SQL I do not have to commit every statement. Perhaps create I don't have to.
So can you answer me which Statements I have to commit?
I read, that I have to commit all transactions, but I don't know what this is and can't find it anywhere.
Thanks for your help.
Per the SQL standard, most statements that require a transaction will automatically open one.
Some database engines, such as SQL Server, will (by default) automatically commit the transaction if the statement completes successfully. See Autocommit Transactions.
Autocommit mode is the default transaction management mode of the SQL Server Database Engine. Every Transact-SQL statement is committed or rolled back when it completes
SQL Server also has an Implicit Conversions mode which will leave the transaction open until it's explicitly commited.
When operating in this second such mode (which is the default, I believe, for Oracle), or if you've explicitly created a transaction, it's up to you as a developer when to commit the transaction. It should be when you've accomplished a "complete" set of operations against the database.
If you BEGIN a transaction then you have to either ROLLBACK or COMMIT
Example:
BEGIN TRAN
--Your code
INSERT INTO
NewTable
SELECT *
FROM TABLE
COMMIT TRAN
If you do not use that, it is committed upon execution. So the follow will either fail or be committed:
INSERT INTO
NewTable
SELECT *
FROM Table
If there is an error (like there is no NewTable in the DB) the execution will raise an error and the transaction will roll back. If there is no error the transaction will be committed.
If I connect to an oracle database as user smith, and issue the following 3 commands:
update smith.tablea
set col_name = 'florence' where col_id = 8;
insert into bob.other_table#mylink
values ('blah',2,'uncle','new');
commit;
Does this mean that the update to the local table (smith.tablea) and the insert to the remote db table (bob.other_table) have both been committed or that just the update to the local table has been committed?
Note: that 'mylink' represents a dblink to a remote database.
From documentation
The Oracle two-phase commit mechanism is completely transparent to
users who issue distributed transactions. In fact, users need not even
know the transaction is distributed. A COMMIT statement denoting the
end of a transaction automatically triggers the two-phase commit
mechanism to commit the transaction. No coding or complex statement
syntax is required to include distributed transactions within the body
of a database application.
so - yes, if everything goes fine, both operations are commited.
In this case the transaction should only work if the remote transaction and your local transaction are successfull.
More information about distributed transactions:
http://docs.oracle.com/cd/B19306_01/server.102/b14231/ds_txnman.htm
Can the SQL "truncate table" command be used within a transaction? I am creating an app and my table has a ton of records. I want to delete all the records, but if the app fails I was to rollback my transaction. Deleting each record takes a very long time. I'm wondering if I use truncate table, can I still rollback the transaction and get my data back in the event of a failure. I realize that truncate table doesn't write each delete to the transaction log, but I'm wondering if it writes the page deallocation to the log so that rollback works.
In SQL Server, you can rollback a TRUNCATE from a transaction. It does write page deallocation to the log, as you mentioned.
In Oracle, TRUNCATE TABLE is a DDL statement that cannot be used in a transaction (or, more accurately, cannot be rolled back). AFAIK, if there is a transaction in progress when the statement is executed, the transaction is committed and then the TRUNCATE is executed and cannot be undone.
In Informix, the behaviour of TRUNCATE is slightly different; you can use TRUNCATE in a transaction, but the only statements permissible after that are COMMIT and ROLLBACK.
Other DBMS probably have their own idiosyncratic interpretations of the behaviour of TRUNCATE TABLE.
If you read the official documentation of PostgreSQL, It said that The TRUNCATE TABLE statement is transaction-safe.