Die grosse SQL Mathematik

[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

[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

[Fuerchau]

SQL kennt natürlich auch noch den Typ Decimal für die Arithmetik, da Float ja Fließkomma ist.
SQL versucht halt, bei Zwischenergebnissen so viele Nachkommastellen wie möglich zu verwenden, was bei Divisionen schon mal knapp werden kann. Das führt auch schon mal dazu, dass mit decimal(31, 29) gerechnet wird und in der Folge sogar zu Dezimalfeldüberlauf.
Wenn dann auch noch aggregiert wird, muss u.U. das maximum herausgeholt werden.
Aus sum(dec(11,2)) wird dann auch schon mal ein dec(31, 18).
Eine tatsächliche Regel daraus abzuleiten habe ich mir abgewöhnt und rechne nun z.T. mit Zwischenergebnissen, gerade um Integerarithmetik zu vermeiden.

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

Wobei der Zwangscast ab und an auch leider ignoriert wird.

[Fuerchau]

Warum verweigerst du dich der Angabe von Nachkommata bei 100 und 19?