Die grosse SQL Mathematik

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

[BenderD]

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?

... beide, wobei bei der sum Variante, die Anzahl der erwarteten Sätze in die Berechnung eingeht. Erwartet die Query engine sehr viele Sätze, könnte das Ergebnis sehr groß werden und es verzichtet eher auf Nachkommastellen - was hier eine Rolle spielen könnte (insofern bin ich nicht bei Baldur).
Wenn es hier um kaufmännisches rechnen geht, ist der Ansatz eh verkehrt, da muss man Rundung erzwingen und sich um overflow/underflow kümmern.

D*B

[ILEMax]

@Baldur
ich verweigere mich nicht
Die 19 hat (im Orginal) sowieso 2 NK Stellen

Interaktiv im STRSQL bringt

select sum(1,25)/100,00*19,00 from uniqueDatei where uniqueKey in(1, 2) --> 2 Sätze

das Ergebnis 0,00! Was ich noch weniger verstehe

Im RPG haben wir uns angewöhnt mit eval(RH) zu arbeiten.
Das übersetzen wir mit: 'Bitte rechne richtig'
(oder mit einer Funktion, die das Runden, den Überlauf und die Fehlermeldung händelt)

Wenn SQL das bei Dieter und Birgitta richtig macht, fehlt uns irgend etwas, oder ist schlecht eingestellt.
Das wüsste ich gerne!

[BenderD]

@Baldur
ich verweigere mich nicht
Die 19 hat (im Orginal) sowieso 2 NK Stellen

Interaktiv im STRSQL bringt

select sum(1,25)/100,00*19,00 from uniqueDatei where uniqueKey in(1, 2) --> 2 Sätze

das Ergebnis 0,00! Was ich noch weniger verstehe

Im RPG haben wir uns angewöhnt mit eval(RH) zu arbeiten.
Das übersetzen wir mit: 'Bitte rechne richtig'
(oder mit einer Funktion, die das Runden, den Überlauf und die Fehlermeldung händelt)

Wenn SQL das bei Dieter und Birgitta richtig macht, fehlt uns irgend etwas, oder ist schlecht eingestellt.
Das wüsste ich gerne!

... Fehlermeldung => PTF

[B.Hauser]

Es passiert folgendes, da nichts gecastet wird, wird das Ergebnis der Summe mit als Dec(31, 2) ausgegeben. Da durch ein Integerwert dividiert wird, der ja keine Dezimal-Positionen hat, wird das Ergebnis der Division ebenfalls mit Dec(31, 2) ausgegeben und dann weitergerechnet. Allerdings ist das Ergebnis 2,5/100 = 0,025. Die 5 wird abgeschnitten (also 0,02) und dann mit 19 multipliziert ergibt ,038.

Das andere kann ich nicht erklären.
Warum das so ist ... wie Dieter sagt, bei der IBM nachfragen.

Aber nachwie vor ist die Regel: Zuerst multiplizeren und dann dividieren!!!
... und auch die komplette Berechnung in sum() integrieren.

[BenderD]

@Baldur
ich verweigere mich nicht
Die 19 hat (im Orginal) sowieso 2 NK Stellen

Interaktiv im STRSQL bringt

select sum(1,25)/100,00*19,00 from uniqueDatei where uniqueKey in(1, 2) --> 2 Sätze

das Ergebnis 0,00! Was ich noch weniger verstehe

Im RPG haben wir uns angewöhnt mit eval(RH) zu arbeiten.
Das übersetzen wir mit: 'Bitte rechne richtig'
(oder mit einer Funktion, die das Runden, den Überlauf und die Fehlermeldung händelt)

Wenn SQL das bei Dieter und Birgitta richtig macht, fehlt uns irgend etwas, oder ist schlecht eingestellt.
Das wüsste ich gerne!

...l welche Variante hast du denn nun?
select sum(1,25)/100,00*19,00 from ...
oder
select sum(1,25/100)*19,00 ?
bei der ersten kommt der sum als dec mit 2 nachkommastellen und die Division durch 100 lässt Stellen verschwinden.
Kommt der Wert aus einer Datei, nimmt er die Nachkommas mit und macht das Feld vor dem Komma größer (wg. sum)

Besser ist es ohnehin, die Division zu dem MwSt Satz zu nehmen:
select sum(...) * MwSt / 100

Macht man jetzt noch einen cast auf das erste Feld und gibt ihm 2 Nachkommas mehr und rundet auf 2 Nachkommastellen am Schluss, sollte das stabil sein!

D*B