Re: Wrong execution plan
From: Joerg Jost <joerg.jost_at_unitrade.com>
Date: Wed, 10 Jun 2009 16:57:37 +0200
Message-Id: <1244645858.3848.46.camel_at_localhost>
Am Mittwoch, den 10.06.2009, 15:26 +0100 schrieb Nigel Thomas:
> Jorg
>
> Just two possibilities to quickly rule out before all the more complex
> possibilities are debated:
> * check that the datatypes of the PL/SQL variables are all
> appropriate and no implicit datatype conversions are taking
> place - I expect pos_num is a NUMBER; is l_tmp_num1 also?
> * check that the there's no NLS conversion issues (language or
> character set)
>
Date: Wed, 10 Jun 2009 16:57:37 +0200
Message-Id: <1244645858.3848.46.camel_at_localhost>
Am Mittwoch, den 10.06.2009, 15:26 +0100 schrieb Nigel Thomas:
> Jorg
>
> Just two possibilities to quickly rule out before all the more complex
> possibilities are debated:
> * check that the datatypes of the PL/SQL variables are all
> appropriate and no implicit datatype conversions are taking
> place - I expect pos_num is a NUMBER; is l_tmp_num1 also?
> * check that the there's no NLS conversion issues (language or
> character set)
>
Hi Nigel,
your first point, the variables are declared with po.pos_num%type. Of course this is also right for the other ones. So this should be safe.
Your second, i am not absolutely sure to get the right point. The database runs in NLS_CS we8iso8859p15 with language german_germany.
There is no conversion in this procedure, as far as i can see. There is no to_char, to_number or something similar.
Thx
Jörg
-- You can have it: Fast, Right or Cheap, pick 2 of the 3. Fast + Right is Expensive Fast + Cheap will be incorrect. Right + Cheap will take a while. -- http://www.freelists.org/webpage/oracle-lReceived on Wed Jun 10 2009 - 09:57:37 CDT