Delphi und
ADO:
SQL-Code:
select 12/100*0.5 from dual; => 0
select 0.5/100*12 from dual; => 0
select 0.1*(12/100*0.5) from dual; => 0
select 0.1*(0.5/100*12) from dual; => 0
select (12/100)*0.5 from dual; => 0
select (0.5/100)*12 from dual; => 0
select 0.1*(12/100)*0.5 from dual; => 0
select 0.1*(0.5/100)*12 from dual; => 0
FlameRobin
SQL-Code:
select 12/100*0.5 from dual; => 0,0
select 0.5/100*12 from dual; => 0,0
select 0.1*(12/100*0.5) from dual; => 0,00
select 0.1*(0.5/100*12) from dual; => 0,00
select (12/100)*0.5 from dual; => 0,0
select (0.5/100)*12 from dual; => 0,0
select 0.1*(12/100)*0.5 from dual; => 0,00
select 0.1*(0.5/100)*12 from dual; => 0,00
Interessant finde ich, das die Anzahl der Nachkommastellen im Ergebnis jedesmal der Summe der Nachkommastellen in der Rechnung Entspricht.
Nein, das ist nicht interessant, haben wir schon in der Schule gelernt: Wenn man zwei Zahlen mit Nachkommastellen multipliziert, so erhält man im Ergebnis soviele Nachkommastellen, wie die multiplizierten Zahlen zusammen enthalten.
Zwei Nachkommastellen * zwei Nachkommastellen = 4 Nachkommastellen.
https://de.bettermarks.com/mathe/mul...dezimalzahlen/
Ok, wenn man sich das Ergebnis über FlameRobin anschaut, so stimmt das, die Regel wird eingehalten.
Über Delphi und
ADO werden die Nachkommastellen (bei Beachtung der Regel) jedoch nur ausgegeben, wenn sie <> 0 sind.
Taschenrechner & Co. scheinen da etwas "flexibler" zu sein, sie erweitern die Nachkommastellen implizit, wenn es für eine korrekte Darstellung des Ergebnisses erforderlich scheint.
Fazit: Rechnen über Select nur, wenn man sich der Einhaltung dieser Regel bewusst ist.