SQL - Insert mit select berechnung eines Wertes

[nico1964]

Wenn Du bei der Funktion DEC/DECIMAL, weder Länge noch Nachkommastellen angibst, woher soll er wissen, dass Du 8, 7 (wobei ich auf mindestens 11, 7 gehen würde) willst?

ggf. kannst Du noch auf 7 Stellen mit Funktion ROUND kaufmännisch runden.

Birgitta

Hallo Birgitta,

könntest Du mir dabei bitte helfen, damit ich das Ergebnis auf 8, 7 kriege, den ich bekomme jetzt
einen Überlauf wie du richtig angemerkt hast.
Rechne zum ersten mal mehr als nur summen oder Subtraktion mit SQL bin ein alter COBOL-Programmierer und alt im sprichwörtlichen Sinn.

LG
Andreas

[KingofKning]

Ist zwar Microsoft, funktionier aber auch unter AS/400.

https://msdn.microsoft.com/de-de/library/ms187746%28v=sql.120%29.aspx

Alternativ:
http://www-01.ibm.com/support/knowle...f_decimal.dita

In Summe: dec(10, 2) = 10 Stellen davon 2 Nachkomma.

GG

[Fuerchau]

Du musst die Funktion um deine Summe packen:
dec(sum(...), 15, 7)

Beachte dabei, dass das Ergebnis abgeschnitten wird, ggf. mach noch einen Round im Dec:
dec(round(sum(...), 7), 15, 7)

Beachte auch, dass es zu einem SQL-Fehler kommt, wenn das Ergebnisi > 8 Stellen vor dem Komma wird.

[nico1964]

Du musst die Funktion um deine Summe packen:
dec(sum(...), 15, 7)

Beachte dabei, dass das Ergebnis abgeschnitten wird, ggf. mach noch einen Round im Dec:
dec(round(sum(...), 7), 15, 7)

Beachte auch, dass es zu einem SQL-Fehler kommt, wenn das Ergebnisi > 8 Stellen vor dem Komma wird.

ich habe das DEC(....), 8, 7) eingebaut, was mir folgende Einzelergebnisse vereinfacht dargestellt liefert:
1. Berchnung 2. Berechnung 3.Berechung
5.000.000,00 + 0,80 / 15.000.000,00
wobei 1. Berechnung und 2. Berechung zusammen und 3.Berechnung alleine max. 99.999.999,99 ergeben können und 1 + 2 / 3 maximal 1,0000000

und bekomme jetzt folgenden Fehler


Nachrichten-ID . . . . : SQL0406 Bewertung . . . . . . : 30
Nachrichtenart . . . . : Diagnose
Sendedatum . . . . . . : 16.02.09 Sendezeit . . . . . . : 09:49:01

Nachricht . . . : Umsetzungsfehler bei der Zuordnung zu Spalte LGD_COV.
Ursache . . . . : Bei dem Versuch, Spalte LGD_COV mit einer Anweisung
INSERT, UPDATE, ALTER TABLE oder REFRESH TABLE einen Wert zuzuordnen, ist
ein Umsetzungsfehler der Art 1 aufgetreten. Wurde eine Vorkompilierung
durchgeführt, ist der Fehler aufgetreten, als eine numerische Konstante in
dieselben Attribute wie Spalte LGD_COV umgesetzt werden sollte. Mögliche
Fehlerarten sind:
-- Fehlerart 1 - Überlauf.
-- Fehlerart 2 - Gleitkommaüberlauf.
-- Fehlerart 3 - Gleitkommaunterlauf.
-- Fehlerart 4 - Gleitkommaumsetzungsfehler.

Wenn ich den Aufruf native ausführe bekomme ich für die Berechnung folgendes Ergebnis(auszugsweise):

Ausdruck CASE
2.512.556,6900000000000000
289.699,7500000000000000
91.641,2900000000000000
3.894.073,4600000000000000
360.586,9500000000000000
5.436.586,2500000000000000
2.633.054,1000000000000000
10.516.225,7000000000000000
16.044.414,2000000000000000
2.674.854,3700000000000000
4.499.917,6500000000000000

und hier noch der aktuelle auszug aus dem sqlstatement
dec(((decimal(dwht1.expeigcov * double(t67.lgdcov)/100, 13 , 2) +
decimal(dwht1.expeigunco * double(t67.lgduncov)/100, 13 , 2)) /
(dwht1.expeigcov + dwht1.expeigunco - dwht1.zussisum)), 8, 7),

[Fuerchau]

dec(Ausdruck, 8, 7) = 8 Stellen, davon 7 Nachkomma
deshalb
dec(Ausdruck, 15, 7) = 15 Stellen, davon 7 Nachkomma, also 8 Vorkomma

[nico1964]

dec(Ausdruck, 8, 7) = 8 Stellen, davon 7 Nachkomma
deshalb
dec(Ausdruck, 15, 7) = 15 Stellen, davon 7 Nachkomma, also 8 Vorkomma

geändert aber leider der selbe Fehler, bin kurz vor dem verzweifeln oder ich sehe den Wald vor lauter Bäumen nicht mehr

[KingofKning]

Dann geh doch mal überall auf 30,5 und schau mal ob es läuft.
Sollte wirklich groß genug sein ;-)

Vielleicht hast Du ja einen Ausreißer in den Zahlen.

Alternativ mal ein Query und da die Summe berechnen lassen.

GG

[Fuerchau]

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.

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