MS SQL Genauigkeit in der Termauswertung

[Delphi.Narium]

Was kommt denn bei Dir da so raus?

Firebird:
select 0.1 * (12 / 100 * 0.5) as a, 0.1 * (0.5 / 100 * 12) as b from dual; liefert hier 0 und 0

select 0.1 * (12 / 100 * 0.500) as a, 0.1 * (0.500 / 100 * 12) as b from dual; liefert hier 0 und 0,006

select 0.100 * (12 / 100.000 * 0.5000) as a, 0.100 * (0.5000 / 100 * 12) as b from dual; liefert hier 0,006 und 0,006

hä???

Da wird also "innendrinnen" irgendwie implizit gerundet auf die Zahl der da gerade (zufällig) anwesenden oder eben auch nicht anwesenden Nachkommastellen.

Oder anders ausgedrückt:

Wir haben hier Ganzzahl- und Nachkommazahlen.

Da wird eine Typkonvertierung gemacht, entweder auf Ganzzahl oder auf Nachkommazahl. Und dann wird da "irgendwie" entsprechend gerundet

Achso: Bevor ich es vergesse:

Die Ergebnisse mit einem Delphiprogramm über die ADO-Komponenten (s. o.) sind andere, als die über FlameRobin:

select 0.1 * (12 / 100 * 0.5) as a, 0.1 * (0.5 / 100 * 12) as b from dual; liefert 0,00 und 0,00

select 0.1 * (12 / 100 * 0.500) as a, 0.1 * (0.500 / 100 * 12) as b from dual; liefert 0,0000 und 0,0060

select 0.100 * (12 / 100.000 * 0.5000) as a, 0.100 * (0.5000 / 100 * 12) as b from dual; liefert 0.0060000000 und 0.0060000

Upps

[Moombas]

@Delphi.Narium: Kannst du mein Beispiel mit der Klammersetzung auch mal ausgeben und Posten (oder rein editieren)? Würde mich einfach mal interessieren.

Zitat von Delphi.Narium:

Die Ergebnisse mit einem Delphiprogramm über die ADO-Komponenten (s. o.) sind andere, als die über FlameRobin:

select 0.1 * (12 / 100 * 0.5) as a, 0.1 * (0.5 / 100 * 12) as b from dual; liefert 0,00 und 0,00

select 0.1 * (12 / 100 * 0.500) as a, 0.1 * (0.500 / 100 * 12) as b from dual; liefert 0,0000 und 0,0060

select 0.100 * (12 / 100.000 * 0.5000) as a, 0.100 * (0.5000 / 100 * 12) as b from dual; liefert 0.0060000000 und 0.0060000

Upps

Interessant finde ich, das die Anzahl der Nachkommastellen im Ergebnis jedesmal der Summe der Nachkommastellen in der Rechnung Entspricht. Also sonst auch mal probieren (wo man auch immer die Stellen platziert, wenn man vorher wissen muss wie viele Nachkommastellen man haben muss finde ich das Suboptimal):

select 0.1 * (12 / 100 * 0.50) as a, 0.1 * (0.50 / 100 * 12) as b from dual;

[hoika]

Hallo,

12/100.00 vielleicht?

[TigerLilly]

Ja, so erhalte ich das erwartete Ergebnis. Wir haben eine Tabelle mit Formeln, die vom SQL Server ausgewertet werden + ich bin sehr sehr sicher, dass das früher anders funktioniert hat. Der 2008R2 ist schon Jahre im Einsatz + das Problem ist jetzt erst aufgepoppt.

Wir werden wohl in allen Formeln die Skalare mit .0 ergänzen.

[jobo]

keine Ahnung ob diese Beobachtung nun so ist wie sie ist, aber wenn, dann:
Mal bei MS nachschlagen, solche Änderungen werden eigentlich nicht "einfach so" mal ins Feld geworfen. Es müsste dazu Migrationshinweise geben und normalerweise auch Schalter, die das (alte) Verhalten bewahren, forcieren usw.

Kommt natürlich bei der Art der Anpassung auf das zu erwartende Änderungesvolumen an und wie exakt man die Problemstellung überhaupt finden kann.

[hoika]

Hallo,
hm, also hier

https://docs.microsoft.com/en-us/pre...v%3dsql.110%29

steht

The precision and scale of the numeric data types besides decimal are fixed. If an arithmetic operator has two expressions of the same type, the result has the same data type with the precision and scale defined for that type.

Und weiter unten ist noch eine Tabelle.

Das war also schon immer so, zumindestens beim 2012-er

[TigerLilly]

Vielleicht ist das bei uns auch einfach durchgerutscht und die Erinnerung siegt über Tatsachen. Oder - wie es so schön heisst: Die Wahrheit ist eine Tochter der Zeit.

Das Problem gibt es wahrscheinlich auch nur, wenn man das SQL Statement als Text zusammenbaut, sonst hat man eh Paramter und passende Datentypen.

Aber zum Merken: <int> <op> <int> liefert <int>.

[Delphi.Narium]

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

Zitat von Moombas:

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.

[TigerLilly]

Du machst die Sache kompliziert, denn hier geht es um MS-SQL Server. DUAL gibt es für den nicht und wie ich beschrieben habe, sind die Ergebnisse andere:

select 12/100*0.5 --> 0
select 0.5/100*12 --> 0,06

[p80286]

Von einer nicht ganz kleinen DB bin ich es gewohnt,daß ich für jeden numerischen Wert das gewünschte Ausgabeformat definiert habe. Und das hat ganz gut funktioniert.
Mit irgendwelchen Seiteneffekten zu rechnen ohne daß mich jemand für meine Genialität feiert war mir auf Dauer zu anstrengend.

Gruß
K-H