Re: 10g Bug with Numeric Precision/Scale?

James Carr schrieb:
> I've found a 10.1.0.4.0 machine
>
> SQL> select * from v$version;
>
> BANNER
> ----------------------------------------------------------------
> Oracle Database 10g Enterprise Edition Release 10.1.0.4.0 - 64bi
> PL/SQL Release 10.1.0.4.0 - Production
> CORE 10.1.0.4.0 Production
> TNS for Solaris: Version 10.1.0.4.0 - Production
> NLSRTL Version 10.1.0.4.0 - Production
>
> I still get the same strange behaviour as on 10.1.0.3
>
> 1.23100007
> 1.23
> 1.23
> 1.231
> 1.23100007
> 1.23100007
> 1.23100007
> 1.231
>
> Daniel, when you tried it on 10.1.0.4.0 how did you get the correct
> answer?
>
> ~
> James
>

I could reproduce this behaviour on 10gR2 as well. Moreover, ( docs states , parameter declared with %TYPE or %ROWTYPE are constrained, also no difference to previous versions http://download-uk.oracle.com/docs/cd/B19306_01/appdev.102/b14251/adfns_packages.htm#sthref773 ), the same "loss of control" seems to be in place with varchar2 datatype:

scott_at_ORA102> create table a(a varchar2(5));

Table created.

scott_at_ORA102> create or replace procedure b(p a.a%type)

   2 is
   3 l_a varchar2(100);
   4 begin
   5 l_a := p;
   6 dbms_output.put_line(l_a);
   7 end;
   8 /

Procedure created.

scott_at_ORA102> set serveroutput on
scott_at_ORA102> exec b('Hello, world!')
Hello, world!

PL/SQL procedure successfully completed.

scott_at_ORA102>

I assume , it is most likely a bug (maybe in documentation, if that was changed in 10g to be not constrained parameter declaration) .

Best regards

Maxim Received on Wed Sep 07 2005 - 13:05:11 CDT