SQL, eringefallen wegen nachkomma stellen

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

[camouflage]

Der Vollständigkeit hab ich mir noch die Zeit genommen für den in RPG native:
feld += (feld/100 * mwst);

Resultat: 10.35!

Kein weiterer Kommentar - auch nicht über SQL.

[Fuerchau]

Man muss unterscheiden
- Endergebnisse werden immer abgeschnitten, sie müssen ggf. erundet werden Round() / eval(h)
- Zwischenergebnisse werden in SQL und ILERPG leider unterschiedich behandelt.
Im ILERPG-Handbuch gibts eine ausführliche Erklärung, bei SQL finde ich so schnell nichts.

[BenderD]

- Zwischenergebnisse werden in SQL und ILERPG leider unterschiedich behandelt.
Im ILERPG-Handbuch gibts eine ausführliche Erklärung, bei SQL finde ich so schnell nichts.

... ich habe keinen Bock, in Handbüchern zu suchen, was ein Programm macht, wenn ich nicht klar sage, was ich haben will. Ich sage stattdessen genau, was ich haben will.
Sprich: geschachtelte Ausdrücke nicht übertreiben und im Zweifel per cast und round festlegen, wie ich das gerechnet haben will.

D*B

[Fuerchau]

Leider hilft der Cast auf Zwischenergebnisse auch nicht immer.
Bei einer komplexeren Berechnung bekam ich auch kein erwartetes Ergebnis und ein NULL-Anzeiger brachte eine Warnung -2.
Laut Joblog und einer ESC-Nachricht war ein Zwischenergebnis leider bzgl. der Nachkommastellen nicht mehr darstellbar und die Berechung wurde abgebrochen.
Kein Dec-Cast war dazu in der Lage ein Zwischenergebnis zu bekommen.
Letzte Lösung: Cast auf Double der Einzelwerte und zum Schluss ein

round(dec("komplexer Ausdruck", 18, 9), 2)

Und das Ergebnis war korrekt. Dasselbe in ILERPG funktionierte ohne Probleme.