01.09.2021 09:29, Molnár Attila wrote:
In dialect 3 you have to cast to double always for not to loose precision.
I believe you may avoid the casts if you store everything as NUMERIC
inside the db, but your procedures use DOUBLE (or better DECFLOAT) for
inputs/outputs/locals.
Dmitry
Alex,
http://www.firebirdsql.org/pdfmanual/html/isql-dialects.html
"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."
On 2021-09-01 18:20, Alex Peshkoff via Firebird-devel wrote:
On 9/1/21 7:13 PM, Omacht András wrote:
(Or please support D1 and don’t force developers to rewrite existing
codebase.)
May be I've missed something - but did we have plans to remove Dialect
1? It seems that not.
Technically,
On 9/1/21 7:13 PM, Omacht András wrote:
(Or please support D1 and don’t force developers to rewrite existing codebase.)
May be I've missed something - but did we have plans to remove Dialect
1? It seems that not.
Firebird-Devel mailing list, web interface at
Mark,
before Attila started this discussion we asked a development colleague who has
also been developing Firebird-based systems for a long time.
Here is his sort answer:
"The truth is that we sucked it with D3 15 years ago. Therefore, when we
started the new system, we released the numeric
On 2021-09-01 15:40, Molnár Attila wrote:
Ok, I understand it's not "wrong", works as designed/intended. Just
put into documentation.
Also, how do you expect to people to leave dialect 1 when dialect 3
gives no benefit, in both dialect extra effort needed to get
calculations right, plain
Ok, I understand it's not "wrong", works as designed/intended. Just put into
documentation.
Also, how do you expect to people to leave dialect 1 when dialect 3 gives no
benefit, in both dialect extra effort needed to get calculations right, plain
operation and funcation usage is not enought to
Molnár Attila wrote 01.09.2021 8:29:
The problem: why the storage format has affect on calculation. It just feels
wrong.
It is ordinary thing in all programming languages when data types decide
calculation rules. In the Delphi product of integer division used to be floating
point, but
"I suggested you start a discussion about your wish that dialect 1 would not be
dropped"
Oh, sorry for the misunederstanding.
After your comment on the GitHub issue I understand how the calcuation works.
The problem: why the storage format has affect on calculation. It just feels
wrong.
I did
