Blas Rodriguez Somoza, in a message posted to the Java group, wrote:
> ...For instance, for Integer the values must be between
2^31-1(2.147.483.647) and -2^31 (2.147.483.648) which are exactly the
> limits is interbase, so the integer type in interbase can be mapped to
java.sql.Types.INTEGER.
>=20
> For BIGINT(equivalent to Long) this means that the field must
allow values from 2^63-1 to -2^63 without loosing of precision,
> what is not true for NUMERIC(18,0). So NUMERIC(18,0) can't be mapped
to BIGINT because it can't containt values between the max and
> min of a BIGINT without loosing precision, and the tests with setLong
on this field will fail because the value get will be
> different from the one set.
>=20
> So the mapping NUMERIC(18,0) to BIGINT is an illegal one and must
be removed until firebird have a INT64 field.
So, having reviewed this note and finding that the basic details where
correct, it immediately begged the questions:
How did Borland manage to claim that NUMERIC( 18, 0) was equivalent to
64 bit integer? =20
(2^63-1 =3D=3D 9223372036854775807, 19 digits)
Then, by extension isn't the INT64 alias incorrect/invalid?
Looking for enlightment.
Sean
|
