64-bit ints -- I'll give it a 9.9. It would have gotten a 10.0
except for that crash but reported with 24 hours of Tuesday's
release. (Though, perhaps that is really a genid problem, not a 64
bit int problem....)
(Hi Chris!)
Dave
> > From: "Geoff McInnes" <gmcinnes@a...>
> > Date: Wed, 2 Aug 2000 19:05:28 -0500
> >
> > May I politely enquire as to where exactly things
> > are wrt 64 bit integers [hopefully from Mssrs Schnepper,
> > Karwin etc?]
> >
> > On a scale of 1 to 10 with
> >
> > 1 = An army of coders will take 6 months to complete
> >
> > 10 = Its there just flick a switch?
> >
> > Thank you
>
> 64-bit integers are integral (<g>) to IB 6.0. You don't even have
to
> flick a switch: just use SQL dialect 3 (6.0 native mode).
>
> In a dialect-3 database, any column declared as NUMERIC(n,m) or
> DECIMAL(n,m) where n >= 10 is implemented as a 64-bit integer, and
all
> arithmetic involving only INTEGER, SMALLINT, DECIMAL, or NUMERIC
data
> is done using scaled 64-bit integers. If you want literally an
> integer of that size, just declare your domain or column as
> DECIMAL(18) or DECIMAL(18,0).
>
> In an ODS 10 (version 6.0 native) database, generators are also 64
> bits, and wrap around after 2**64 invocations, not 2**32 as in
> previous releases. For compatibility, an application using SQL
> dialect 1 will actually see the least significant 32 bits out of the
> 64 bits stored in a generator, while a dialect-3 application will
get
> the full 64. Even when a 32-bit app uses gen_id(), the full 64 bit
> value is incremented: a dialect-3 app that comes along and uses the
> same generator a moment later will get the next value in correct
> 64-bit-integer arithmetic, not a 32-bit wraparound.
>
> --
> Chris Jewell developer/sysadmin voice: 831-
431-6531
> cjewell@i... InterBase Software fax: 831-431-6510