Subject | Re: [ib-support] Re: NUMERIC(18,2) problem |
---|---|
Author | Daniel Rail |
Post date | 2002-04-30T18:52:52Z |
At 04/30/2002 02:38 PM, you wrote:
originally Dialect 1, so that I could transfer data and structure from
Paradox to IB, 2 years ago. Then I converted to Dialect 3. In the
documentation, it mentions that if the precision is 10 and above in Dialect
1, it is DOUBLE PRECISION that is used to store the value and in Dialect 3
it's INT64. But, if you convert from Dialect 1 to Dialect 3, it still is
DOUBLE PRECISION. I think that the proper conversion would have to be
done, because how long would this compatibility can be maintained with
future versions of Firebird.
Also, this helped me in enforcing the proper rounding for financial data,
by adding code in my application, so at least it doesn't use the IEEE
banker's rounding, which my users didn't like. Now, I only need to find or
create a UDF to do this kind of rounding.
Any way, thanks for your attention, I should've been able to find this
information on my own, but somtimes talking about it makes you think harder
I guess. But you got to admit, it's still weird to see this behavior.
Have a nice day.
Daniel Rail
Senior System Engineer
ACCRA Group Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.accramed.ca)
>--- In ib-support@y..., Daniel Rail <daniel@a...> wrote:I found the answer in the IB 6 beta documentation. The database was
> > Dialect 3.
>
>Daniel, what tool did you use to create the table? Does isql.exe
>also report values of three decimal places? Can you extract the
>metadata for the table and post here, thanks.
originally Dialect 1, so that I could transfer data and structure from
Paradox to IB, 2 years ago. Then I converted to Dialect 3. In the
documentation, it mentions that if the precision is 10 and above in Dialect
1, it is DOUBLE PRECISION that is used to store the value and in Dialect 3
it's INT64. But, if you convert from Dialect 1 to Dialect 3, it still is
DOUBLE PRECISION. I think that the proper conversion would have to be
done, because how long would this compatibility can be maintained with
future versions of Firebird.
Also, this helped me in enforcing the proper rounding for financial data,
by adding code in my application, so at least it doesn't use the IEEE
banker's rounding, which my users didn't like. Now, I only need to find or
create a UDF to do this kind of rounding.
Any way, thanks for your attention, I should've been able to find this
information on my own, but somtimes talking about it makes you think harder
I guess. But you got to admit, it's still weird to see this behavior.
Have a nice day.
Daniel Rail
Senior System Engineer
ACCRA Group Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.accramed.ca)