As Ann said, Interbase support 64 integers on the day it was born. Some
idiot at Borland decided that since PC compilers didn't support 64 bit, the
database didn't need to either. That said, I'll bet just about anything
that they never removed the 64 code (In the absence of runtime support for
64 bit, we probably didn't support 64 bit arithmetic.
Failure make version backward compatible is unforgivable and an indication
of bad engineering. Interbase was designed for growth from the begining,
with protocol version numbers, dynamic protocol selection, and a Y-valve
architecture that supported an open ended set of engines. Backwards
compatability is hard to do if you a) consider important and b) think thing
through rather than implementing the first idea that pops into your head.
ODS change is inevitable (why else would I have built in an ODS version
number?). Having an engine support multiple ODS versions is infeasible.
Backwards incompatability is unthinkable. Ergo, a multi-engine server is
necessary.
On Sunday, May 25, 2014, Mark Rotteveel <[email protected]> wrote:
> On 23-5-2014 17:55, Ann Harrison wrote:
> > b) When your database company forces you to rewrite your application
> > (losing arithmetic precision in the process) for the convenience of the
> > company's developers, it's time to consider the cost of moving to a
> > different database.
>
> I think that is a cop out.
>
> That said: I have never understood the exact problem, and from reading
> the old interbase manual the only real problem is that on conversion
> from dialect 1 to dialect 3, NUMERIC and DECIMAL with a precision larger
> than 9 get converted to DOUBLE PRECISION (which they technically already
> where!). Also - according to the Firebird Book II - division in dialect
> 1 is always converted to double precision, and multiplication when the
> precision exceeds 9 will also be converted to double precision
>
> So changing from dialect 1 to dialect 3 seems to trade the false sense
> of precision for actual precision.
>
> So as far as I can see the only problem might be that the current
> implementation does not provide enough precision (ie room) for
> calculations (the scale rules of multiplication and division make you
> run out of room quickly). If that is the actual problem, then we should
> solve that, not continue supporting something that was considered
> deprecated 15 years ago.
>
> And if that is really too much work, we should consider providing a
> number of UDFs (not internal functions!) that do the calculations the
> old way.
>
> Mark
> --
> Mark Rotteveel
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> Firebird-Devel mailing list, web interface at
> https://lists.sourceforge.net/lists/listinfo/firebird-devel
>
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
