I ran the below query.
insert into emp(id,name) values(1,'ONKAR');
then I wrote
Create table emp(id number(10));
it failed because emp table already exist.
then I ran
rollback;
then
select * from emp;
it is returning 1 row.
I know any DDL command after DML will commit the data. But why it is committing even when DDL command failed?
That's because Oracle issues a commit both before and after DDL, as per the documentation:
Oracle Database issues an implicit COMMIT under the following circumstances:
Before any syntactically valid data definition language (DDL) statement, even if the statement results in an error
After any data definition language (DDL) statement that completes without an error
Related
This question already has answers here:
Is it possible to roll back CREATE TABLE and ALTER TABLE statements in major SQL databases?
(5 answers)
Closed 2 years ago.
I found similar queries on stack overflow but was not able to find exact answer.
When I use DDL commands like drop and truncate on SQL Server 2012, I am able to
rollback the changes? In theory, I have always read that you can rollback DML commands but not DDL as they are not logged.
My question is, if DDL commands can also be rolled back? Or this some special feature or settings change in my SSMS which is causing it.
What about the other SQL platforms like Oracle and Postgres? Can we also rollback DDL commands on them?
DDL rolls back.
Example:
BEGIN TRANSACTION
CREATE TABLE a ( Id INT NOT NULL )
SELECT * FROM a -- returns an empty row
ROLLBACK TRANSACTION
SELECT * FROM a -- throws an error, object does not exist
I always include my CREATEs, ALTERs, DROPs and TRUNCATEs inside transactions for that exact reason. That way, if there is an error, I don't get some objects, but not others. Test the DDL you have questions about.
You can use Begin Transaction Block and Rollback - Commit as shown below:
BEGIN TRANSACTION
INSERT INTO YourTable VALUES(1), (2);
ROLLBACK TRANSACTION;
INSERT INTO YourTable VALUES(3),(4);
SELECT [value] FROM YourTable;
DROP TABLE YourTable;
COMMIT TRANSACTION;
and also if you want to do some actions (DDL commands or DML commands) you can turn off Auto commit
First, create a new query page and then, from the menu items: Query\ Query options
Set IMPLICIT_TRANSACTIONS to True
And whenever you did your job, either you can commit your transactions or rollback by commit \ rollback command or by closing page and confirm\reject the transactions
But after that, if your transactions applied to your DB and tables,
You can rollback drop table or truncate table with the Microsoft SQL recovery tool - EaseUS MS SQL Recovery
you will be able to recover the truncated table or recover the table after DROP. EaseUS MS SQL Recovery is a powerful tool to recover deleted or corrupted SQL database data. It can restore deleted SQL data in most situations and repair the corrupted database (the MDF and NDF files).
I have the following script that I run using "isql -i scriptfile.sql":
CONNECT C:\Databasefile.fdb USER user PASSWORD password;
SET TERM !! ;
EXECUTE BLOCK AS BEGIN
IF (EXISTS(SELECT 1 FROM rdb$relations WHERE rdb$relation_name = 'MYTABLE')) THEN
EXECUTE STATEMENT 'DROP TABLE MYTABLE;';
END!!
SET TERM ; !!
CREATE TABLE MYTABLE
(
MYCOLUMN VARCHAR(14) NOT NULL
);
The very first time I run this (when the table does not already exist) the table is created as expected.
If I run the script again I get the following error:
Statement failed, SQLCODE = -607
unsuccessful metadata update
-STORE RDB$RELATIONS failed
-deadlock
After line 8 in file d:\myscript.sql
When the script exits, MYTABLE has been deleted and can no longer be found in the database.
If I run the script a third time the table is once again created and no errors are thrown.
Why can't the script both delete and then recreate a table?
DDL from PSQL is not allowed, using EXECUTE STATEMENT it is not directly forbidden, and usually possible, but still not wise exactly because of these kinds of problems. I am not exactly sure about the reasons, but part of it have to do with how DDL changes are applied in Firebird; the use of execute statement adds additional locks iirc which conflict with a subsequent DDL for the same table name.
Instead of dropping and creating this way, you should use the DDL statement RECREATE TABLE instead.
Note that the word deadlock in this error is actually a bit of a misnomer (there is no real deadlock).
I got a little trouble in SSIS. I have multiple table and i want adding Truncate statement so that table can't create double data.
This is the image of package that I made :
each Data Flow, i used Flat File Source and ADO NET Destination.
And then, in Execute SQL Task i want to apply Truncate Table
After that, i have error message :
"[Execute SQL Task] Error: Executing the query "truncate table Table1
truncate table Tabl..." failed with the following error: "ERROR
[HY000] [Oracle][ODBC][Ora]ORA-00911: invalid character". Possible
failure reasons: Problems with the query, "ResultSet" property not set
correctly, parameters not set correctly, or connection not established
correctly."
What i must suppose to do?
P.S
Sorry if my english is not good
Since the destination is an Oracle Database you should use this syntax:
begin
execute immediate 'truncate table t1';
execute immediate 'truncate table t2';
end;
Does this syntax work:
truncate table table1;
truncate table table2;
Note the semi colons.
Which are the differences between DBMS_UTILITY.EXEC_DDL_STATEMENT and EXECUTE IMMEDIATE?
Fundamentally they do the same thing, which is to provide a mechanism to execute DDL statements in PL/SQL, which isn't supported natively. If memory serves me well, the EXEC_DDL_STATEMENT was available in the Oracle 7 version of the DBMS_UTILITY package, whereas Native Dynamic SQL (EXECUTE IMMEDIATE) was only introduced in 8.
There are a couple of differences. EXECUTE IMMEDIATE is mainly about executing dynamic SQL (as its NDS alias indicates). the fact that we can use it for DDL is by-the-by. Whereas EXEC_DDL_STATEMENT() - as the suggests - can only execute DDL.
But the DBMS_UTILITY version isn't retained just for backwards compatibility, it has one neat trick we cannot do with EXECUTE IMMEDIATE - running DDL in a distributed fashion. We can run this statement from our local database to create a table on a remote database (providing our user has the necessary privileges there):
SQL> exec DBMS_UTILITY.EXEC_DDL_STATEMENT#remote_db('create table t1 (id number)');
I'm not recommending this, just saying it can be done.
I realize I am 9 years late to the reply but there is one additional difference.
dbms_utility.exec_ddl_statement will not execute anything but DDL. If you try to do say an insert, it will not do it. It will also not return an error either so you won't know that you did not insert.
-- drop table kevtemp1;
create table kevtemp1 (a integer);
insert into kevtemp1 values (1);
commit;
begin
insert into kevtemp1 values (2);
end;
/
commit;
begin
DBMS_UTILITY.EXEC_DDL_STATEMENT('insert into kevtemp1 values (3)');
end;
/
commit;
select * from kevtemp1;
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