RE: Re[2]: to_number question

  • From: "rob zijlstra" <rmsah@xxxxxxxxx>
  • To: <oracle-l@xxxxxxxxxxxxx>
  • Date: Mon, 19 Jul 2004 09:37:38 +0200


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
-----------------------------------------------------------------

Other related posts: