-
SQL, eringefallen wegen nachkomma stellen
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
-
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.
Code:
Values(8,70 + 8,70/100,0*19); --> ergibt: 10,35300000000000000000000000000
Alternativ kannst Du natürlich auch 100 explizit auf Dezimal casten.
Code:
Values(8,70 + 8,70*19/Cast(100 as Dec(3, 0))); --> ergibt ebenfalls das richtige Ergebnis
-
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
-
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.
-
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
-
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
Last edited by dibe; 08-11-23 at 09:23.
Grund: Cast auch ausprobiert
-
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)
kf
-
Zitat von 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
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?
-
@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
-
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.
kf
-
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.
Similar Threads
-
By dschroeder in forum NEWSboard Programmierung
Antworten: 14
Letzter Beitrag: 05-04-19, 13:16
-
By Stephan70 in forum NEWSboard Programmierung
Antworten: 3
Letzter Beitrag: 21-12-15, 07:12
-
By svit in forum IBM i Hauptforum
Antworten: 14
Letzter Beitrag: 18-06-15, 09:08
-
By a.wojcik in forum NEWSboard Programmierung
Antworten: 24
Letzter Beitrag: 16-01-15, 15:18
-
By Koelch400 in forum IBM i Hauptforum
Antworten: 10
Letzter Beitrag: 12-10-04, 11:48
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks