View Full Version : SQL, eringefallen wegen nachkomma stellen
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.
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
08-11-23, 12:21
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.
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.
Wenn ein Taschenrechner auch diese "klugheit" hätte, würder ich "falschen" ja verstehen.
Dietlinde Beck
einfache Taschenrechner rechnen meist mit float Arithmetrik, da passieren dann zuweilen andere Dummheiten.
So empfinde ich es als sehr unglückliche Lösung, die auf jeder einfachen SQL Schulung genannt werden sollte.
Dietlinde Beck
... gute Schulungen erwähnen so etwas.
- 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
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.