RE: Wrong results using decode when db upgraded to 9205

  • From: Pete Sharman <peter.sharman@xxxxxxxxxx>
  • To: oracle-l@xxxxxxxxxxxxx
  • Date: Thu, 6 May 2004 02:59:47 +1000

The rule hint will still work but is unsupported.

 =

Pete
 =

"Controlling developers is like herding cats."
Kevin Loney, Oracle DBA Handbook
 =

"Oh no, it's not.  It's much harder than that!"
Bruce Pihlamae, long-term Oracle DBA

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] =
On Behalf Of Duret, Kathy
Sent: Thursday, 6 May 2004 2:45 AM
To: 'oracle-l@xxxxxxxxxxxxx'
Subject: RE: Wrong results using decode when db upgraded to 9205

A question about using the Rule hint for new code?

Forgive me, but isn't the rule going away in 10G and I would assume the rul=
e
hint would no longer work or rather be ignored in 10G so why put rule into
new code to have to rewrite it when you migrate to 10G.

Haven't tested it in 10G so I don't know for sure.  Has anyone?


Kathy

-----Original Message-----
From: Jamadagni, Rajendra [mailto:Rajendra.Jamadagni@xxxxxxxx]
Sent: Wednesday, May 05, 2004 11:26 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: Wrong results using decode when db upgraded to 9205


I just found that the query in question works ... In following
conditions ...

1. using case structure instead of DECODE
2. by running the report with cursor_sharing=3D3Dexact or providing
cursor_sharing_exact hint at statement level
3. Running the select with rule hint.

BTW it is not datatype conversion issue, the actual decode statement is
as follows ...

"and decode('C8','C8','237','0') =3D3D '237'"
=3D20
It is becoming obvious to me that this is an optimizer issue. I'll be
digging further ... =3D20

Raj
------------------------------------------------------------------------
--------=3D20
Rajendra dot Jamadagni at nospamespn dot com=3D20
All Views expressed in this email are strictly personal.=3D20
select standard_disclaimer from company_requirements;=3D20
QOTD: Any clod can have facts, having an opinion is an art !

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Stefan Jahnke
Sent: Wednesday, May 05, 2004 11:56 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: AW: Wrong results using decode when db upgraded to 9205

Hi again

Sorry, haven't looked into it. Since we already changed everything to =3D
=3D3D
CASE on 9.2.0.4.0. The reason wasn't a bug but to be coherent with the =3D
=3D3D
usage of DECODE / CASE. We agreed upon ANSI style stuff (INNER JOIN, =3D3D
CASE blahblah) since 2 developers have a SQL Server background and seem
=3D3D to comprehend that faster (no pun intended, they're great).

Stefan


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



This transmission contains information solely for intended recipient and ma=
y
be privileged, confidential and/or otherwise protect from disclosure.  If
you are not the intended recipient, please contact the sender and delete al=
l
copies of this transmission.  This message and/or the materials contained
herein are not an offer to sell, or a solicitation of an offer to buy, any
securities or other instruments.  The information has been obtained or
derived from sources believed by us to be reliable, but we do not represent=

that it is accurate or complete.  Any opinions or estimates contained in
this information constitute our judgment as of this date and are subject to=

change without notice.  Any information you share with us will be used in
the operation of our business, and we do not request and do not want any
material, nonpublic information. Absent an express prior written agreement,=

we are not agreeing to treat any information confidentially and will use an=
y
and all information and reserve the right to publish or disclose any
information you share with us.
----------------------------------------------------------------
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: