Hi all, Jaromir, I'm sorry, but I disagree. As I see it, some people here want to make it possible that the rdbms will silently cover up 'some' mistake in the system. Well, that should be very nice, but totally unaceptable. Why? Simple, if you know that a certain mistake might occur, it would be a handy feature, but suppose you do not know it and the system just goes on, with maybe totally wrong output? Would you even dare to suggest such a possibility in a production system? And it's really quite easy; if there is garbage in the data, an exception MUST occurs. Also if there's garbage in the way the dba/developer approaches the db, so an exception MUST occur. Never, ever should the system silently 'behind my back' cover up for ANY mistake; I'm master of the system (I hope...) and it should do what I tell it in case of an error and NEVER what it 'thinks' it should do. Just my 2 ct Rob Zijlstra ========================================================================== Jaromir D.B. Nemec wrote: I totally agree with Lex's argumentation, although I accept this is rather *pessimistic* approach. But there is another more optimistic solution avoiding the less optimal BAD values solution proposed early in this thread. Simple the DBMS will suppress any ORA-nnnnn error and will try in a loop the next access path. May be next time the query will be successful! How many time this loop on different execution plans should be repeated? Why not limit it with OPTIMIZER_MAX_PERMUTATIONS:) Regard Jaromir D.B. Nemec ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------