Die grosse SQL Mathematik

[ILEMax]

Moin
aus Zwei Dateien werden 2 relevante Sätze mit diesen Inhalten ermittelt

A_Zahl = 1,25
B_MWES 19,0

Ein

select sum(a_Zahl), (sum(a_Zahl/100)*b_MWES, sum(a_Zahl) + (sum(a_Zahl/100)*b_MWES 
from a inner join b on ... where ... group by ... b_mwes

ergibt
2,5        0,38             2,88

Das krieg ich nicht gebacken

Auch wenn ich

select sum(1,25), (sum(1,25/100)*19, sum(a_Zahl) + (sum(a_Zahl/100)*b_MWES 
from a inner join b on ... where ... group by ... b_mwes

mache, ergibt das 
2,5        0,38             2,88

ist sql defekt oder ist das so eine Wald Baum Geschichte?

[ILEMax]

Um ganz sicher irgendwelche verknüpfungsfehler aus zu schließen habe ich das nun mal so eingegeben

select sum(1,25), (sum(1,25/100)*19 from datei where uniquekey in(1, 2)

= genau 2 Sätze


ergebnis: 2,5 0,38

[Fuerchau]

Gewöhn dir einfach an, mit mehr Nachkommastellen zu rechnen, denn SQL optimiert da dann gerne welche weg:

sum(1,25), (sum(1,25/100,00)*19,00 , sum(a_Zahl) + (sum(a_Zahl/100,00)*b_MWES

[B.Hauser]

Ich würde allerdings zunächst einmal multiplizieren und zum Schluss dividieren.
Ebenso würde ich nicht erst die Summe multiplizieren, sondern jeden einzelnen Betrag und dann die Summe zunächst runden und dann wie gewüscht casten:

Cast(Round(Sum(A_Zahl * b_MWES / 100,00), 11, 2) as Dec(11, 2))

[BenderD]

Um ganz sicher irgendwelche verknüpfungsfehler aus zu schließen habe ich das nun mal so eingegeben

select sum(1,25), (sum(1,25/100)*19 from datei where uniquekey in(1, 2)

= genau 2 Sätze


ergebnis: 2,5 0,38

... mal auf die Schnelle auf dem nächstbesten (verfügbaren) System mit STRSQL ausprobiert:
2,5 , ,4750000000 (reichlich Nullen)

[ILEMax]

Echt?
V7R5?
hier kommt 0,38 anstatt 0,47500

[BenderD]

... V7R3

mit welchem SQL Frontend hast Du Deine Resultate bekommen?

[ILEMax]

Aufgefallen ist das in einem SQLRPGLE Pgm, das normalerweise mehrere 1000 Sätze so berechnet.
Und dann 'richtig' ist.
Durch eine neue Gruppe, die etwas früh Daten geliefert hat, waren es für die nur 2 Sätze, so ist das aufgefallen.
Bei der Fehlersuche habe ich es mit STRSQL in 'grün' nachvollzogen

[BenderD]

... beim SQLRPGLE gibt es da noch Einstellungen (DESRECPOS und solcher Unfug) und Felddimensionen. Der Effekt selber deutet darauf hin, dass die 2.5 entweder abgeschnitten wird oder ganzzahlig gerechnet wird. Dass die 2,5 mit Nachkommas und beim weiterrechnen abgeschnitten wir, lässt mich an einen Fehler denken. Soll der Lieferant der Datenbank doch ermitteln, was da los ist: Softwaredefekt reklamieren.

[B.Hauser]

Wie sind den Deine Felder definiert?
Ich habe auch 7.5 und bei mir kommt das Ergebnis richtig!

Was natürlich zu bedenken ist, in SQL gibt es nur 2 "numerische" Datentypen (Integer und Float).
Die Regel heißt, wenn 2 Integer-Werte mit einander verrechnet werden, ist das Ergebnis wieder ein Integer-Wert. Wenn Du also mit 95/100 dividierst (also 2 Integer) ist das rechnerische Ergebnis 0,95, da nichts gerundet wurde und das Ergebnis wieder eine Ganzzahl ist, ist das Ergebnis null.
Werden Zahlen ohne Dezimal-Trennzeichen angegeben, interpretiert SQL diese als Integer-Werte. Wenn dann auch noch irgendwelche Klammern dafür sorgen, dass 2 Integer-Werte miteinander verrechnet werden, dann kann es leicht zu falschen Ergebnissen kommen.
Deshalb sollte man grundsätzlich wenn man durch eine Zahl/Konstante dividiert, diese immer mit Dezimal-Trennzeichen und mindestens einer Nachkommastelle angeben.

[ILEMax]

Also das ist seltsam ...

Wenn ich es mit strsql mache, sind ja keine Felder beteiligt. ich gebe die Zahlen genau so ein:

select sum(1,25), (sum(1,25/100)*19 from datei where uniquekey in(1, 2)


im RPGSQLLE Pgm sind die Felder
a_Zahl 8,2 und b_MWES 5,2 jeweils gepackt definiert.


Warum ist das hier falsch?
was kann ich noch einstellen? pgm ist angepasst, trotzdem!

[ILEMax]

so nochwas versucht

select 2,5/100*19 from Datei --> 0,47500000
select sum(1,25)/100*19 from uniqueDatei where uniqueKey in(1, 2) --> 2 Sätze --> 0,38

Was habt ihr probiert?
die erste oder die 2. version?