Re: tracking changes on a table through ODBC application

"db dude" <db_guy_2002_at_yahoo.com> wrote in message news:f4a8da28.0307270017.28f23e02_at_posting.google.com...
>
> Thats a pretty wierd interpretation of what a "dirty read" is. As per
> the documentation oracle does not support dirty reads and also does
> not support two out of four standard levels of isolation.

Has it ever occurred to you that the multiple "isolation" levels of other databases are just marketing crap to hide the simple fact they *cannot* support "readers don't block writers"?

Do a bit of research on mainframe databases, hierarchical kind, of 20 years ago. You will find that the holy grail of them all was to get a concurrency implementation that would not cause readers to lock out writers. Oracle has done that since day one. No other RDBMS supports it. Note: I said *RDBMS*.

None of them will openly admit that fundamental flaw of their implementation. Hence the "isolation levels" crap. The basic truth is, if you have a RDBMS that does not block writers with readers, you simply don't give a rat's arse about the isolation level: it's a totally useless feature in such an environment.

> > Please tell us how, reading uncommitted data from some other
> > process is preferable to reading the most recently committed
> > data.
>
> Apparently, the excuse for not supporting "dynamic scrollable cursors"
> (not dynamic sql cursors) is that "dirty reads are never supported."
> which in itself is quite a stupid excuse since dynamic scrollable
> cursors are not supported for data that has been committed by other
> users also.

I note that you still have not answered the *fundamental* question here: "why the bloody heck would anyone in his/her right mind want to read uncommitted data from some other process"? Try to answer that and you'll find why Oracle will simply NOT support something that represents an obvious regression on its concurrency model. Period.

--
Cheers
Nuno Souto
wizofoz2k_at_yahoo.com.au.nospam