Subject | Re: Problems with Numeric(18,5) |
---|---|
Author | alex_vnru |
Post date | 2002-02-13T21:49:45Z |
--- In ib-support@y..., guido.klapperich@t... wrote:
client. It is shurely overflow, casting any of operands to double
precision gives right result. Since I use dialect 1 in my work and
always avoid numerics because in dialect 1 calculated on the fly
result is presented as double and don't give advantages of exact scale
storage but creates problems of this kind, I can't say is it bug or as
designed. Claudio forced FB to raise exception in such a cases but
seems in dialect 1 only. Let's wait while he says his expert word.
Best regards, Alexander V.Nevsky.
> I have a following test-table-70.000,000000
> CREATE TABLE NEW_TABLE (
> MONEY1 NUMERIC(18,4),
> MONEY2 NUMERIC(9,4),
> MONEY3 NUMERIC(18,5));
>
> INSERT INTO NEW_TABLE (MONEY1,MONEY2,MONEY3) VALUES
> (-70000,-70000,-70000);
>
> Now the query:
> select money1,money1/1.95583,
> money2,money2/1.95583,
> money3,money3/1.95583
> from new_table
>
> and the result:
> MONEY1 F_1 MONEY2 F_2 MONEY3
> F_3
> -70000 -35.790,431684 -70.000,000000 -35.790,431684
> 1.936,250234Guido, confirm it on LI-T6.2.681 FB server and WI-T6.2.682 FB
>
> When the field is Numeric(18,5), then IB calculates wrong. Exists
> therefore a logical solution or is it a bug ?
>
>
client. It is shurely overflow, casting any of operands to double
precision gives right result. Since I use dialect 1 in my work and
always avoid numerics because in dialect 1 calculated on the fly
result is presented as double and don't give advantages of exact scale
storage but creates problems of this kind, I can't say is it bug or as
designed. Claudio forced FB to raise exception in such a cases but
seems in dialect 1 only. Let's wait while he says his expert word.
Best regards, Alexander V.Nevsky.