Could be important to say something about the timeframe and the reasons of implicit commiting in DDLs... Regarding timeframe, since many moons ago it is true : in https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:7072180788422 (2002) it was this way, and years before....

Speaking for reasons, the most important one is multi-user consistency : without the implicit commit by definition a ROLLBACK must be possible - what if one user A could create a table, another user B could create an index, what happens to B´s index ? Or what about two users creating the same table(s) with a delayed commit? And what about DROP TABLE statements? Should they be roll backed ?

One could argument for making non-commited DDLs to be "local" only, visible only from the creating session : in this case, how to meaningfully monitor the system and explain SQL as the "noncommitted" table would not exist from the perspective of any other user (or even any other SESSION for the creating user) ??

Complex things to manage... So, to avoid all of this, Oracle wisely opted for implicit commiting on DDLs....

Regards,

J. Laurindo Chiappa

Manuals do not say this - But here's words of wisdom :-

An implicit COMMIT occurs immediately before the database executes a DDL statement
Even if the DDL fails
Even if the DDL fails
Even if the DDL fails

Enjoy !!!

Hi - sorry but the Doc (follow the link provided above) says :

"An implicit COMMIT occurs immediately before the database executes a DDL statement..."

The key word is BEFORE : see, the DDL was NOT executed yet but the COMMIT already was done : so, logically don´t matter if the DDL fails or succeed, the COMMIT (implicit and BEFORE DDL execution) already was done.....

Regards,

J. Laurindo Chiappa