Subject | Re: [IBO] Extracting stored procedure code |
---|---|
Author | Paul Vinkenoog |
Post date | 2003-05-30T13:29:38Z |
Hello Clément,
always 8 for a double, 4 for a float etc.
The precision can be found in the last field: RDB$FIELD_PRECISION
But... it turns out that, as soon as a numeric or decimal field is big
enough to need a double (which only occurs in dialect 1 dbs, like
Employee), only the scale is preserved (it's stored as a negative
integer because the stored double has to be scaled with a factor 10^-n
if you declare a scale n).
The precision (total number of digits) is lost. Tools show it as 15
(the maximum in dialect 1). The difference between NUMERIC and DECIMAL
is also lost. This is not the case if the value can be stored in an
integer.
Fortunately, this loss of information only happens in dialect 1. If
your own database is dialect 3, any NUM/DEC type fits in (at most) an
INT64. You will find the original scale _and_ precision in RDB$FIELDS,
and subtype 1 for numeric, 2 for decimal.
There's a lot of information about this in the Language Reference,
Chapter 7: System Tables and Views.
Greetings,
Paul Vinkenoog
> But ... (you saw that one coming, didn't you?)No, I didn't - honestly! :-)
> I have declared a parameter as being NUMERIC(15,2) and inThe 8 you saw is not the precision but the field length, which is
> rdb$procedure_parameters is shows as (DOUBLE, 8 , -2). You can check
> it in employee.gdb. IBConsole shows as NUMERIC(15,2) but the table
> shows DOUBLE , 8 , -2...
always 8 for a double, 4 for a float etc.
The precision can be found in the last field: RDB$FIELD_PRECISION
But... it turns out that, as soon as a numeric or decimal field is big
enough to need a double (which only occurs in dialect 1 dbs, like
Employee), only the scale is preserved (it's stored as a negative
integer because the stored double has to be scaled with a factor 10^-n
if you declare a scale n).
The precision (total number of digits) is lost. Tools show it as 15
(the maximum in dialect 1). The difference between NUMERIC and DECIMAL
is also lost. This is not the case if the value can be stored in an
integer.
Fortunately, this loss of information only happens in dialect 1. If
your own database is dialect 3, any NUM/DEC type fits in (at most) an
INT64. You will find the original scale _and_ precision in RDB$FIELDS,
and subtype 1 for numeric, 2 for decimal.
There's a lot of information about this in the Language Reference,
Chapter 7: System Tables and Views.
Greetings,
Paul Vinkenoog