MS SQL Genauigkeit in der Termauswertung

[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.

[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

[Moombas]

Zitat von Delphi.Narium:

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.

Jaein, denn: Nimmst du 0,1*0,1 stimmt die Aussage (=0,01) ABER: nimmst du 0,1*1,0 wäre das korrekte Ergebnis 0,1 (die nachstehenden Nullen sind irrelevant, da 0,1 = 0,10).
Und warum das in DIESEM Fall durchaus interessant ist: Das Ergebnis der Rechnung wäre 0,006 (3 Nachkommastellen), wenn nun aber in der Rechnung (0.1 * (0.5 / 100 * 12)) nur 2 Nachkommastellen vorkommen und daher davon ausgegangen wird, das man nur 2 Nachkommastellen braucht ist das Ergebnis logischerweise Falsch!
Folglich müsste man generell mit der maximal möglichen Anzahl an Kommastellen rechnen um einigermaßen vernünftig rechnen zu können (und keine Angst haben muss, das dadurch Kommastellen schlichtweg gestrichen werden). Daher:
0.1 * (0.5 / 100 * 12) = 0.00
0.1 * (0.50 / 100 * 12) = 0.006 (?)

@Tigerlilly:

Zitat von 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

Was ist denn das Ergebnis wenn du folgende Rechenoperationen ausführst:
select (12/100)*0.5 --> ?
select 12/100*0.50 --> ?

[TigerLilly]

Zitat von Moombas:

0.1 * (0.5 / 100 * 12) = 0.00
0.1 * (0.50 / 100 * 12) = 0.006 (?)

Also, das ist jetzt ein bissl off-topic, aber zurück zu dem, was der MS-SQL wirklich ausgibt:

0.1 * (0.5 / 100 * 12) = 0.006
0.1 * (12 / 100 * 0.5) = 0.0

(0.5 / 100 * 12) = 0.06
(12 / 100 * 0.5) = 0.0
(12.0 / 100 * 0.5) = 0.06
(12 / 100.0 * 0.5) = 0.06

Wie gesagt: die Genauigkeit einer Operation wird durch die Genauigkeit ihrer Operanden definiert. Daher ergibt 12/100 IMMER(!) 0, egal wo im Term es steht.

Jetzt weiß ich es.