Path: news.cambrium.nl!textnews.cambrium.nl!feeder3.cambrium.nl!feed.tweaknews.nl!postnews.google.com!a3g2000prm.googlegroups.com!not-for-mail From: Noons Newsgroups: comp.databases.oracle.server Subject: Re: Why Oracle does not allow rollback of DDL statements? Date: Mon, 10 Nov 2008 22:37:36 -0800 (PST) Organization: http://groups.google.com Lines: 48 Message-ID: References: <57ce7648-b6db-4e34-ad52-4dc171ceb0a9@v16g2000prc.googlegroups.com> <6nqbkgF7okkU1@mid.individual.net> <6nqmdfFafviU1@mid.individual.net> NNTP-Posting-Host: 203.202.124.168 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1226385456 14274 127.0.0.1 (11 Nov 2008 06:37:36 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 11 Nov 2008 06:37:36 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: a3g2000prm.googlegroups.com; posting-host=203.202.124.168; posting-account=oJZDiQoAAAD-FXU2V1mvdIjuYivOHSlr User-Agent: G2/1.0 X-HTTP-Via: 1.0 AUSYD-PROXY01 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3,gzip(gfe),gzip(gfe) Xref: news.cambrium.nl On Nov 10, 11:06=A0pm, Serge Rielau wrote: > That's the first I hear about that. Can you point to any docs explaining > the behavior you imply? I'm also told that SQL Server (like DB2) has > transactional DDL. Even TRUNCATE table is transactional. Instead of reading marketing materials, try using the product. I'm stuck with having to use it, so rather than reading "tickmarks" from a marketing "competitive" list, I aqctually have to deal with the blessed thing. It is supposed to *be* there. However, it is so inconsistent as to make it essentially unusable. For example: Try to drop a table that is not there - a common example of a "oops" statement in an upgrade script. It produces an error, but does NOT cause a rollback to take place or lock other scripts out. Now, try to select form an incorrect table name - another common example os a "oops" statement in an u[grade script. It produces an error, and DOES put the transaction in a suspended state that is neither rollback nor commit: if you are running the script interactively, you then have to manually take a decision on which way it goes. Do a search around the forums to see what folks are using to run upgrade scripts - the example given to "reinforce how useful it is". *NO* one recommends that transactional DDL be used. Exactly and precisely because it is not consistent in how it handles errors and what causes an auto or manual rollback of a transaction in error. Let's not get into logfile overheads... Which makes it, to me, essentially the equivalent of "not there": couldn't care less what the marketing nonsense says. > Oracle has to sort out timing today. The only difference is that it has > a statement level view on things rather than a transaction level view. Yup. I can live with that.