View Full Version : Unterschiedliche Summen im Sql
Hallo liebes Forum,
ich habe im Programm ein Sql-Statement
EXEC SQL
SELECT SUM(B1MIN)
INTO :SUMME :MyIndikator
FROM ZA1, ZB1
WHERE
A1AUF = :A2AUF AND A1AUF = B1AUF AND
A1PNR = :B1PNR AND A1PNR = B1PNR AND
A1KZ1 = :A1KZ1 AND
A1FNR = :B1FNE AND
A1GNR = :A1GNR AND
A1TNR = :A1TNR AND
A1ZNR = :A1ZNR;
Wenn ich aber dies in der Interaktive SQL-Sitzung aufrufe,
bekomme ich eine andere Summe geliefert.
Mit dem Debugger habe ich kontrolliert ob die richtigen Werte übergeben werden.
Es wird mir im Dspjoblog auch kein Fehler angezeigt und der Sqlcod ist auch null.
Kann mir da bitte jemand einen Tip geben?
Dank im Voraus
Tarki
Ich würde da glatt behaupten, dass dies nicht sein kann, der Fehler sitzt vor dem Bildschirm :).
Wie sicher bist du, dass du den Inhalt der Hostvariablen korrekt in STRSQL übernommen hast?
Ein kleiner Tippfehler rächt sich da schon.
Stimmt die LIBL für beide Abfragen überein?
Und, eher der unwahrscheinliche Fall, stimmen Commt-Definitionen überein?
D.h.: Wenn du Commit=*CHG im Programm hast, werden ggf. nicht committete Daten anderer Jobs überlesen, STRSQL arbeitet per Default mit Commit=*none.
Ach ja, könnten die Daten zwischenzeitlich geändert sein?
Hallo,
habe wirklich zig mal geprüft.
Bin mir ja eh sicher das das Problem wieder vor dem Bildschirm sitzt, aber Selbsterkenntnis ist der 1 Schritt zur Besserung oder? :)
In den H-Bestimmungen habe ich definiert
H BndDir('BNDDIR')
H DEBUG(*YES)
H DftActGrp(*NO)
HOption(*srcstmt : *nodebugio)
weiters
EXEC SQL Set Option Commit = *None, DatFmt = *ISO;
Die Hostvariablen habe ich im Debugger geprüft aber anscheinend prüft er immer nur die 1. laufende Nummer(A1FNR).
Bekomme immer das selbe Ergebnis.
lg
Ändere mal den SQL auf die korrekte Form um:
select ...
from ZA1
inner join ZA2 on ...
where ...
Die "alte" Form "F1, F2, ..." wird nur noch toleriert.
Der Grund ist die "Sonderbehandlung" bei STRSQL, die vielfach anders optimiert um möglichst schnell Daten anzuzeigen.
Wie man dem das abgewöhnen kann, habe ich auch noch nicht gefunden.
...
- inner join oder cross join darf keine Rolle spielen, das wäre ein Bug und kein Feature.
- Optimierung (kann man mit optimize clause beeinflussen)darf keine Rolle, das wäre ein bug und kein feature
- Unterschiede auf Grund der Verwendung anderer Datentypen (interaktives SQL versus Select into) könne auftreten und sind ein feature und kein Bug.
D*B
PS: ob die Probleme vor dem Bildschirm dann Bug oder Feature sind, da kenne ich beide Varianten (nicht abhängig vom Bildschirm)
Die Frage ist ggf. noch, ob der Indicator ggf. gesetzt ist.
Ansonsten:
Ich bin der festen Überzeugung, dass vor meinem Bildschirm ein Feature sitzt :).
Der ist definiert.
DPGMSDS sds
D SDSPGM 10a
D SDsts 5s 0
D SDprvsts 5s 0
D SDsrcstmt 8a
D SDroutine 8a
D SDparms 3s 0
D SDmsgid 7a
D SDmi# 4a
D SDwork 30a
D SDlib 10a
D SDerrdta 80a
D SDrpgmsg 4a
D SDFiller01 69a
D SDJOB 10a
D SDSUSR 10a
D SDjobnum 5s 0
D SDjobdate 6s 0
D SDrundate 6s 0
D SDruntime 6s 0
D MyIndikator 5I 0
D MsgText 91 170
D MsgTextKurz 91 140
MYINDIKATOR = 0
SQLCOD = 000000000.
SQLSTT = '00000'
Werde nun die korrekt Form ausprobieren.
Gruß
Tarki
Habe diese Form probiert aber liefert das gleich falsche Ergebnis wie das andere Statemnt.
EXEC SQL
SELECT SUM(B1MIN)
INTO :SUMME :MyIndikator
FROM ZA1 INNER JOIN ZB1
ON
A1AUF = :A2AUF AND A1AUF = B1AUF AND
A1PNR = :B1PNR AND A1PNR = B1PNR AND
A1KZ1 = :A1KZ1 AND
A1FNR = :B1FNE AND
A1GNR = :A1GNR AND
A1TNR = :A1TNR AND
A1ZNR = :A1ZNR;
andreaspr@aon.at
30-08-13, 19:55
Starte einfach mal ein DB-Monitoring und schau dir den Zugriffsplan im Detail an.
Dort solltest du erkennen können ob irgendwo irgendwelche CASTs oder ähnliches gemacht wird, was dein Ergebnis verfälschen könnte.
Wenn du die Statements im Visual Explain nebeneinander Vergleichst bekommst du sicher einen Hinweis.
lg Andreas
Hallo,
1. um andere Bibbliotheken auszuschliessen
(zum Test die Dateien qualifiziert lesen )
2. wie Baldur geschirieben hat
select felder
join mit Schlüsselfelder
where die variablen
3. MyIndicator
ist der in der SDS wirklich richtig positioniert ?
Gruß
Michael