SQL - Insert mit select berechnung eines Wertes

[nico1964]

Lass einfach mal das zwischendurch casten weg und erzwinge Nachkomma:

select sum(((t67.lgdcov * 0,01 * expeigcov) +
(t67.lgduncov * 0,01 * expeigunco)) /
(expeigcov + expeigunco - zussisum))
from lea/leadwht1, lea/leat67 t67

Ein cast auf Double verliert Genauigkeit und erzwingt ein Runden oder abschneiden des Ergebnisses.
Ggf. ersetze 0,01 mit 0.01, je nach Dezimalzeichen.
Schau dir die Ergebnisse an.

Ggf. brauchst du das Ergebnis wieder nicht zu casten sondern stellst dies in eine Hostvariable deines Formates. Mit einem NULL-Anzeiger erfährst du auf Satzebene (-2), wann der Wert nicht passt.

Danke Baldur perfekte Lösung.

mfg
Andreas

[Fuerchau]

Wichtig bei den ganzen Rechnereien ist die Berechnung der Anzahl Nachkomma.
Sind in der Formel (innerhalb einer Klammerebene) ausschließlich Ganzzahlen beteiligt, wird eine Ganzzahlenarithmetik verwendet. Diese ergibt niemals Nachkomma.
Bei der Verwendung von Konstanten kann man Nachkomma erzwingen wenn man eben welche angibt.
An Stelle also "/ 100" kodiert man "/ 100,00". Wenn man Multiplikation verwendet kann wird es eindeutiger und schneller (macht schon ein paar Nanos aus).
Sind alle beteiligten Ganzzahlen reicht der cast einer einzigen Variablen.
Statt also "a / b" dann eben "a / dec(b, 11, 2)".
SQL berechnet dann eben die Anzahl Gesamtstellen bis halt hin zu dec(Ausdruck, 31, n) unter möglicher Beibehaltung der Genaugkeiten.
Hier kann man (ähnlich wie in ILERPG) mit Zwischenrundungen und casts das Ergebnis beeinflussen:
"dec(round(a / dec(b, 11, 2), 2), 11, 2"
Round rundet nur kaufmännisch ohne das Format anzupassen, die Nachkomma werden also nicht gekürzt. Die Zwischenanpassung ist auch manchmal erforderlich, wenn SQL an seine Grenzen stößt und mehr als 31 Stellen benötigt werden. Dies kann man zwar mit SQL-Optionen auf 63 erhöhen, löst aber das Problem meist nicht.

Nach Möglichkeit sollte man den cast auf Double vermeiden. Man kann damit bei 10^+/-308 rechnen aber die Genauigkeit bleibt bei 14 Stellen!
Und gerade bei den Nachkommastellen fangen die Rundungsprobleme an, denn round(double(0,333), 2) ergibt leider ungefähr 0,33000000000012 und damit wird dann weiter gerechnet.

[BenderD]

... ist (leider) nur fast richtig:
wichtig ist zuerst, ob SQL ganzahlig oder mit Nachkomma rechnet und das entscheidet sich an der ersten Rechenoperation im staement:
select 1/3 + 4 from sysibm.sysdummy1 liefert 4
select 1/3 + 4.0 ... immer noch 4
select 1/3.0 + 4 ... jetzt 4.33333
nachträglicher cast, round und Zuweisung an ein entsprechend dimensioniertes Feld hilft hier nix mehr (Zuweisung hat niedrigste Prio)
Unangenehmer Nebeneffekt hier ist, dass die Reihenfolge der Rechenoperationen vo, Statement abhängen kann (Optimizer).

Analoges gilt für Gleitkomma Berechnungen; da man hier nicht wirklich steuern kann wo die Genauigkeit hingelegt wird, sollte man das bei kaufmännischen Anwendungen immer meiden.

Beim runden muss man noch im Auge haben, dass man vor Aggregation rundet, sonst sind die Summen auf verschiedenen Aggregationsstufen nicht konsitent!

Dasselbe gilt bei Berechnungen, die auf Dreisatz beruhen (Menge mal Preis/Einheit etc.), sowie beim Aufschlag von Märchensteuer (ist hier kein SQL Phänomen).

Literale in Berechnungen vermeiden, besser Werte aus einer Parameterdatei holen und dazu joinen, oder jedes Literal casten, damit man sicher den Datentyp kennt.

D*B

Wichtig bei den ganzen Rechnereien ist die Berechnung der Anzahl Nachkomma.
Sind in der Formel (innerhalb einer Klammerebene) ausschließlich Ganzzahlen beteiligt, wird eine Ganzzahlenarithmetik verwendet. Diese ergibt niemals Nachkomma.
Bei der Verwendung von Konstanten kann man Nachkomma erzwingen wenn man eben welche angibt.
An Stelle also "/ 100" kodiert man "/ 100,00". Wenn man Multiplikation verwendet kann wird es eindeutiger und schneller (macht schon ein paar Nanos aus).
Sind alle beteiligten Ganzzahlen reicht der cast einer einzigen Variablen.
Statt also "a / b" dann eben "a / dec(b, 11, 2)".
SQL berechnet dann eben die Anzahl Gesamtstellen bis halt hin zu dec(Ausdruck, 31, n) unter möglicher Beibehaltung der Genaugkeiten.
Hier kann man (ähnlich wie in ILERPG) mit Zwischenrundungen und casts das Ergebnis beeinflussen:
"dec(round(a / dec(b, 11, 2), 2), 11, 2"
Round rundet nur kaufmännisch ohne das Format anzupassen, die Nachkomma werden also nicht gekürzt. Die Zwischenanpassung ist auch manchmal erforderlich, wenn SQL an seine Grenzen stößt und mehr als 31 Stellen benötigt werden. Dies kann man zwar mit SQL-Optionen auf 63 erhöhen, löst aber das Problem meist nicht.

Nach Möglichkeit sollte man den cast auf Double vermeiden. Man kann damit bei 10^+/-308 rechnen aber die Genauigkeit bleibt bei 14 Stellen!
Und gerade bei den Nachkommastellen fangen die Rundungsprobleme an, denn round(double(0,333), 2) ergibt leider ungefähr 0,33000000000012 und damit wird dann weiter gerechnet.

[Fuerchau]

Nur zur Erklärung:
"(innerhalb einer Klammerebene)", damit meine ich auch implizite Klammern der Punkt- vor Strichrechnung.

[nico1964]

Erst mal herzlichen Dank Baldur für die Hilfe gestern, das ist wieder mal ein Projekt, das Ergebnis schon vor einem Monat bekannt sein hätte sollen.

Und dann nochmals danke an Dich und Dieter für die ausführliche Erklärung in euren letzten 2 Beiträgen, welche ich in meine Sammlung "So geht es richtig" kopiert habe.

Ich hätte aber noch eine Frage. Kennt ihr jemanden der InHouse Schulungen anbietet zugeschnitten auf bestimmte Anforderungen. Ich hätte nämlich die Möglichkeit so was zu bewilligen lassen, wenn es sich um ein vernünftiges Preis-Leistungs-Verhältnis handelt . Wir würden dabei einen Anforderungskatalog zusammenstellen, was wir gerne vertiefen oder teilweise auch neu lernen würden.

Unser Profil: mind. 2 max. 4 Personen wobei bei 4 ist eine Person dabei, welche mit SQL nicht so viel am Hut hat.
Alle 4 so ca. 20 Jahre AS400 Erfahrung und keiner unter 50. Ich bin mit meinen fast 52 der Benjamin in der Abteilung aber auch der Chefprogrammierer.

Ort wäre no na das wunderschöne Wien.

Gruss aus dem verregneten Wien
Andreas

[Fuerchau]

Wenn du mit mir vorlieb nehmen willst ruf mich an .......

[B.Hauser]

Nun ja, da gibt es natürlich auch noch einige andere hier im Forum, z.B.
Andreas Prousza
oder meine Wenigkeit

Birgitta

[nico1964]

Wenn du mit mir vorlieb nehmen willst ruf mich an .......

Guten Morgen,
gerne werde ich Dein Angebot annehmen, ich will nur warten bis mein Boss und mein Kollege, welcher sicher dabei sein will, wieder im Büro sind. Ich melde mich Anfang nächster Woche bei Dir.

Schönen Aschermittwoch noch
Gruss
Andreas

[BenderD]

... wenn man sich denn über die Themen einig wird, mache ich sowas auch. Ansonsten findet man die üblichen Verdächtigen per Tante Google...

D*B

[nico1964]

Nun ja, da gibt es natürlich auch noch einige andere hier im Forum, z.B.
Andreas Prousza
oder meine Wenigkeit

Birgitta

Guten Morgen Birgittas,

ich werde mich mit meinem Boss und meinem Kollegen besprechen, dann werden wir zusammenschreiben was wir uns vorstellen und alle hier bereits genannten kontaktieren.
Ist das ein fairer Vorschlag?
Schönen Aschermittwoch aus Wien
Andreas
p.s. den Andi Prouza kenne ich sogar persönlich

[andreaspr@aon.at]

Nun ja, da gibt es natürlich auch noch einige andere hier im Forum, z.B.
Andreas Prousza
oder meine Wenigkeit

Birgitta

Danke Birgitta :-) .