SQL, eringefallen wegen nachkomma stellen

[dibe]

Hallo zusammen

ich errechne in einem SQL die Mwst

nicht als "* 1,19" sondern

sum(feld) +((sum(feld)/100)*MWSTFELD)

Feld ist 7,2
MWSTFELD ist 5,2

In meinem Fehler habe ich einen Satz, mit dem FELD : 8,70

Ich reche 8,70 + 8,70/100*19 = 10,35
Sql errechnet 10,22
Intern ist für SQL 8,7/100 nur 0,08
auch ein DEC(sum(feld)+((sum(feld)/100)*mwstfeld), 7, 2)
ändert das nicht.

Kann ich irgendwie, am besten Global, das interne unnützue abschneiden abstellen damit er mit 0,087 weiterrechnet ?
Da ist ja jeder dumme Taschenrechner richtiger!

Vielen Dank
Dietlinde Beck

[B.Hauser]

Wenn du eine konstante Zahl ohne Nachkomma-Stellen angibst wird diese als Integer-Wert interpretiert.
Die Regeln bei Integer-Werten sind etwas anders:
1. Werden 2 Integer-Werte miteinander verrechnet ist das Ergebnis wieder ein Integer-Wert, also 95/100 ergibt rein rechnerisch 0,95, da aber bei Integer-Werten irgendwelche Nachkommastellen abgeschnitten werden und da an dieser Stelle nicht gerundet wurde, ist das Ergebnis 0.
2. Die Anzahl der Nachkommastellen wird bei der Rechnung mit Integer-Werten nicht erhöht. Deshalb kommt auch bei 8,7/100 nur 0,08 heraus.
Die einfachste Lösung ist, wenn Du anstatt 100 100,0 angibtst. 100,0 wird als Fließkomma interpretiert und das ganze Problem mit dem "falschen" Rechnen entfällt.

Values(8,70 + 8,70/100,0*19); --> ergibt: 10,35300000000000000000000000000

Alternativ kannst Du natürlich auch 100 explizit auf Dezimal casten.

Values(8,70 + 8,70*19/Cast(100 as Dec(3, 0))); --> ergibt ebenfalls das richtige Ergebnis

[dibe]

Hallo Frau Hauser, vielen Dank!

...das ganze Problem mit dem "falschen" Rechnen entfällt.

Wenn ein Taschenrechner auch diese "klugheit" hätte, würder ich "falschen" ja verstehen.
So empfinde ich es als sehr unglückliche Lösung, die auf jeder einfachen SQL Schulung genannt werden sollte.
Es ist einfach unüblich, bei einer Berechnung extra zu erwähnen, das man es "richtig" haben möchte.
Obwohl ..... im RPG habe ich mich an EVAL(RH) als grundsätzlichen Rechenbefehl gewöhnt.

Danke für die schnelle Hilfe.
Dietlinde Beck

[Fuerchau]

Ich verwende häufiger statt "/ 100" eher "* 0,01";-).
Damit ist das Ergebnis dann dezimal mit 4 Nachkomma.

Die Integerarithmetik schlägt nur zu, wenn alle Operanden Integer oder Ganzzahlen sind.
Wenn ich also "dec(8.70, 11, 2) / 100" schreibe erhalte ich auch 0,087 mit 22 Dezimalen.

[dibe]

Na ja, das besonders ärgerliche ist ja, das der 'übliche' Test im interaktiven SQL,

Select 8,7/100 from Datei

0,0870000000 bringt

Da kommt doch keiner drauf, das das im SQLRPGLE PGM dann nur noch 0,08 ist

[dibe]

Korrektur:
/100,00 oder /100.00 kann SQL gar nicht! (interaktiv)

sum(feld1)+((sum(feld1)/100,00)*Feld2)
mit feld1 = 8,70 und feld2 = 19,00
und der definition Feld1 = 7,2 bzw Feld2 5,2
ergibt 8,70

auch
/Cast(100 as Dec(3, 0)) ergibt 8,70 !!!
auch mit 100.00 kommt 8,70 heraus



mit *0,01 ist das ergebnis OK

Fehler oder Feature?

Danke Herr Fuerchau
Dietlinde Beck

[camouflage]

Ich hab mir halt angewöhnt bei solchen Operationen die Division am Schluss zu machen oder Felder mit genügend Kommastellen. Hast Du das auch ausprobiert?
sum(feld) +((sum(feld)*MWSTFELD)/100)

[Andreas_Prouza]

Na ja, das besonders ärgerliche ist ja, das der 'übliche' Test im interaktiven SQL,

Select 8,7/100 from Datei

0,0870000000 bringt

Da kommt doch keiner drauf, das das im SQLRPGLE PGM dann nur noch 0,08 ist

Wie sieht denn dein Code aus?
Ich hab jetzt mal schnell ein Beisipel gemacht und hab das erwartete Ergebnis im RPG bekommen.:

dcl-s l_1 packed(5 : 3);

exec sql set :l_1 = 8.7 / 100;

dsply (%char(l_1));


Ergebnis: DSPLY .087

Oder hab ich was falsch verstanden?

[dibe]

@carmuflage
Das geht auch.
Wiederspricht aber irgendwie der Aussage von Frau Hauser, das die 100 anstatt einer 100,00 schuld ist.

@Herr Prouza
Es ist ein

insert into Datei
select sum(...

in einem SQLRPGLE Pgm, nicht *FREE V7R5 alle PTF

Die Felder in der Zieldatei sind alle mit 2 NK-Stellen.

Fazit:
Division als letztes (Carmuflage) geht,
*0,01 anstatt /100 (Fuerchau) geht auch
/100 rechnet (Ich), aber das ergebnis ist abgeschnitten (0,08 statt 0,087)
/100,00 oder /100.00 oder /Cast(100 as Dec(3, 0)) (Frau Hauser) rechnet nicht, Ergebnis 8,70

Für meine Kollegen und mich nicht wirklich logisch!

Danke an alle
Dietlinde Beck

[camouflage]

Doch Dietlinde,
das ist durchaus logisch. Wenn Du ein Feld mit 7.2 definierst, werden halt die übrigen Dezimalstellen abgeschnitten. Siehe Beispiel Andreas, welcher die dritte Stelle erhalten hat. Daher, Dezimal genügend gross oder Division am Schluss.

[dibe]

Warum ist es logisch, das, wenn ich 2 NK Stellen im ERGEBNIS haben möchte, alle Zwischenergebnisse auch nur 2 NK haben. Darauf habe ich doch keinen Einfluß! das das Endergebnis nicht gerundet sonder abgeschnitten ist, kann ich verstehen. Das die Berechnung sich in Zwischenergebnissen an den dezimalstellen des Ergebnisses orientiert halt ich für einen Fehler
Es erschließt sich mir nicht.
Aber ich werde versuchen es mir zu merken.

[B.Hauser]

Wenn das Ausgabe-Feld nicht alle Dezimal-Stellen halten kann, wird abgeschritten, so ist nun mal die Aufbereitung.
Es sei denn, Du hättest auf die Anzahl der ausgegebenen Dezimal-Positionen explizit gerundet.
Das hat aber nichts mit SQL zu tun, wie auch die Regeln für die Rechnung mit Integer und Float nichts mit SQL zu tun haben. Das ist nun mal so in "nicht-kaufmännischen" Programmiersprachen und die Datenbank und das SQL dahinter sind fast ausschließlich in C programmiert.
Die RPG und Cobol-Programmierer sind nun mal verwöhnt, weil beides kaufmännische Programmiersprachen sind, bei denen man eine feste Anzahl an Nachkommastellen haben muss und bei denen auch bei der Division von 2 Integer-Werten das Ergebnis Nachkommastellen hat.

I.Ü. haben zumindest die meisten "alten" RPG-Programmierer gelernt, dass man immer zuerst multiplizeren und erst zum Schluss dividieren sollte.