| Subject | RE: [firebird-support] Re: Why this procedure crashes server |
|---|---|
| Author | Leyne, Sean |
| Post date | 2016-12-28T16:09:06Z |
Geoff,
My own memory has IB 6 in beta when Inprise open-sourced the entire thing... IB 6 was finally released but only sometime after Firebird project was started in 2000 and Inprise changed their mind about the whole open-source thing.
The most significant issue with dialect 3 is the "stupid" interpretation that Inprise made of the SQL standard when it comes for handling of precision in math operations -- our application had way too many processes that expected the dialect 1 handling/treatment that the cost of "re-tooling" and testing was much too high.
IMO, the dialect 3 math precision handling is so bad, that if I had to make a fresh choice today, I would still choose dialect 1. So, personally, I don't blame anyone for making the same choice.
We are hoping that Firebird will adopt more "logical/appropriate" rules for dialect 3, there has been talk of same. Until then, we will keep using dialect 1 for as long as possible.
Sean
> I am curious as to why you are using dialect 1 on an FB3 database.Did IB 6 actually get released?
>
> Back when Interbase 6 was released the 1999 language reference said:
> "Dialect 1 exists to ease the migration of legacy databases."
My own memory has IB 6 in beta when Inprise open-sourced the entire thing... IB 6 was finally released but only sometime after Firebird project was started in 2000 and Inprise changed their mind about the whole open-source thing.
> More currently, the FirebirdSQL website ( http://firebirdsql.org/manual/isql-In our case, having started using IB v4.x, we have been locked-in to dialect 1 and we are using v2.5 (looking at v3.x).
> dialects.html ) says:
>
> "Currently it is possible to create databases in Dialect 1 and 3 only, however it
> is recommended that you use Dialect 3 exclusively, since Dialect 1 will
> eventually be deprecated. Dialect 2 cannot be used to create a database
> since it only serves to convert Dialect 1 to Dialect 3." [the highlighting is mine]
The most significant issue with dialect 3 is the "stupid" interpretation that Inprise made of the SQL standard when it comes for handling of precision in math operations -- our application had way too many processes that expected the dialect 1 handling/treatment that the cost of "re-tooling" and testing was much too high.
IMO, the dialect 3 math precision handling is so bad, that if I had to make a fresh choice today, I would still choose dialect 1. So, personally, I don't blame anyone for making the same choice.
We are hoping that Firebird will adopt more "logical/appropriate" rules for dialect 3, there has been talk of same. Until then, we will keep using dialect 1 for as long as possible.
Sean