Re: Oh, lovely!......

From: Noons <wizofoz2k_at_gmail.com>
Date: Wed, 7 Mar 2012 16:57:47 -0800 (PST)
Message-ID: <ed72cf3d-79ed-4785-9f97-04b68750dac9_at_sv8g2000pbc.googlegroups.com>



On Mar 7, 12:26 pm, Mladen Gogala <gogala.mla..._at_gmail.com> wrote:

>
> That is because you are using evil AiX and not good Linux or Solaris:
>

I'm renowned for my "eeeeeevil" ways!
Afer all, I do "strange things" to databases, don't I? Or at least that's the theory from those who "have never met me but know how I work"...
:-)

> On the other hand, a silly question: is your AIX using IPv6?  I
> distinctly remember reading something like that, but as I am not using, I
> am haven't paid much attention to it. If that is IPv6 configuration, your
> Oracle might be right.

It's IPV4. You're absolutely right, with IPV6 the SYS_CONTEXT thingie stops working.
I wonder what will happen then? We need to be able to get the IP Address of a client, no matter what. Ah well, I'm sure Oracle will then give us instead some stored Java monstrosity that will consume umpteen CPU cycles to return a simple value that can be obtained from the command line in a fraction of a microsecond. Never underestimate the power of Java coders to stuff up a fast system...

This one was easy to resolve. I had an auto logon script that went via local memory connection instead of going through the tns alias I usually go through to test address checking. Result of too many days spent trying to work around the many "features" of a 11.2.0.3 upgrade...

Did you know that 10.2.0.3 does not check for table alias names for column naming uniqueness in SQL statements with more than one table? Error ORA-00918 is not produced as a result. Check this one out:http:// stackoverflow.com/questions/4269205/why-doesnt-oracle-raise-ora-00918- column-ambiguously-defined-for-this-query When we upgraded to 11.2.0.3, it promptly threw out the code of one of our M$ "genius"coders.
He'd been getting away in 10.2.0.3 without table aliases in his SQL for years, and now of course the error is Oracle's fault...

So, it's allright to get away with murder if one doesn't get caught and then once one is caught, it's OK to blame the system for not having caught them earlier...

I'll never cease to be amazed at the ignorance of some developers. Don't they teach defensive coding techniques anymore? The best way to avoid future SQL syntax and optimizer issues has always been to code more information than one strictly needs to make a statement compile and work. I guess that's too dba1.0 for some?... Received on Wed Mar 07 2012 - 18:57:47 CST

Original text of this message