My point wasn't to pick any particular detail
of any particular example . I was merely making
the point that whilst the concept of DDL without
commits seems to be straightforward, the requirement
for designing something that could analyse and handle
all the consequent errors that might be a non-tr
Agreed. There's a lot of code out there that was developed considering the
way Oracle handled DDL and DML specifically.
Although I would have liked Oracle to handle DDL as an Autonomous Transaction
and provide an error message for the scenario in the first example, I guess
it might be too late to
that you are at a safe commit point.
jared
"Mercadante, Thomas F" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
01/24/2003 09:34 AM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
cc:
Subject:
Tom - I think you've nailed it. Think of the design decisions that some of
Oracle's competitors made in the early days and how silly they seem in
retrospect. Anyone remember the row-locking vs. block-locking wars?
The other aspect that many people don't think of if they have never
worked in
Hemant,
My guess is that Oracle, at some point in time long ago, decided that DDL's
and DML's should not be mixed together. Because they could not (or did not
want to) deal with the issue, they decided to perform an implicit commit
before any DDL statement was issued. Case closed. This is the w
Take your first example :
insert into t1 values (1);
drop table t1;
-- how to deal with self-deadlock ?
insert into t1 values (2);
commit;
Why does Oracle HAVE to commit when the DROP TABLE is issued ?
What if the INSERT had been issued by another session ? Would
the DROP TABLE go through in