Note in-line.
--
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
The educated person is not the person
who can answer the questions, but the
person who can question the answers -- T. Schick Jr
One-day tutorials:
http://www.jlcomp.demon.co.uk/tutorial.html
____Belgium__November (EOUG event - "Troubleshooting")
____UK_______December (UKOUG conference - "CBO")
Three-day seminar:
see http://www.jlcomp.demon.co.uk/seminar.html
____UK___November
The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
"G M" <zlmei_at_hotmail.com> wrote in message
news:50a5e6b6.0310230612.6743834a_at_posting.google.com...
> Well, if what you said is true then this query would also fail:
>
>
> select distinct to_number(Curationdetails.text)
> from Curationdetails, termlist
> where context = 3001817 and
> CurationDetails.Text=to_char(termlist.TermID)
> and Curationdetails.text='3357971';
>
Not strictly true - when this query is used as
an IN subquery, the optimizer may choose to
do some form of unnesting that could change
the order of predicate evaluation.
>
> But it did not fail in 9i. So I don't think it is data issue in this
> particular case.
>
Same issue - if 9i (which happens to do more unnesting
than 8i) used a different execution path, then the order
of predicate evaluation could change.
Check the paths with EXPLAIN PLAN. You could also
try re-running the simpler query with the
/*+ ordered_predicates */
hint, swapping the order of the two predicates
non-join predicates to see if this made any difference,
and then with the /* ordered */ hint as well and
swapping the table order to see if there is a path
for the simple query which does result in the
same conversion error
> Guang
>
>
> "nobody" <nobody_at_nowhere.com> wrote in message
news:<aTFlb.17823$h61.11522_at_news01.bloor.is.net.cable.rogers.com>...
> > your to_number(Curationdetails.text) fails because of the data in
your 9i
> > table not the version.
> >
Received on Thu Oct 23 2003 - 15:39:45 CDT
