Re: NUMBER Vs NUMBER(38)

A copy of this was sent to Doug Cowles <dcowles_at_bigfoot.com> (if that email address didn't require changing) On Wed, 25 Aug 1999 14:52:17 -0400, you wrote:

>That's not quite right - you can insert floating point values in a
>NUMBER(38) as well.

true, you can insert them but you'll lose fractional values. consider:

tkyte_at_8.0> create table t ( x number(38), y number );

Table created.

tkyte_at_8.0>
tkyte_at_8.0> insert into t values ( 1.1, 1.1 );

1 row created.

tkyte_at_8.0>
tkyte_at_8.0> select x, y, x-y from t;

         X Y X-Y
---------- ---------- ----------

         1 1.1 -.1

>There is actually no difference as far as internal storage goes. The
>number 567 will consume the same amount of storage in both. It is more
>meaningful for the application
>to indicate what the precision is, but both cases they contain 38 digits
>of precision.
>

but the of decimal places is very different.... they have the same precision (number of digits) but a number(38) is the same as number(38,0) so the scales are different (scale being the number of digits to the right of the decimal)

>Michel Cadot wrote:
>
>> NUMBER is a floating point number with precision of about 38 digits
>> in the ranges:
>> range -9.9999999999999999999999999999999999999x10^125 to -1x10^-130 ;
>> 0 ;
>> range 1x10^-130 to 9.9999999999999999999999999999999999999x10^125
>>
>> NUMBER(38) is an integer of 38 digits max.
>>
>> Nandakumar a écrit dans le message <7ps95q$jhf$1_at_nnrp1.deja.com>...
>> >Is there any difference between datatype declarations
>> >NUMBER and NUMBER(38)?
>> >--
>> >Nandakumar
>> >(N.Kumar_at_rocketmail.com)
>> >
>> >
>> >Sent via Deja.com http://www.deja.com/
>> >Share what you know. Learn what you don't.
>
>

--
See http://govt.us.oracle.com/~tkyte/ for my columns 'Digging-in to Oracle8i'... Current article is "Part I of V, Autonomous Transactions" updated June 21'st  

Thomas Kyte                   tkyte_at_us.oracle.com
Oracle Service Industries     Reston, VA   USA

Opinions are mine and do not necessarily reflect those of Oracle Corporation Received on Wed Aug 25 1999 - 15:36:18 CDT