Unterschiedliche Summen im Sql

[tarkusch]

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

[Fuerchau]

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?

[tarkusch]

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

[Fuerchau]

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

[BenderD]

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

[Fuerchau]

Die Frage ist ggf. noch, ob der Indicator ggf. gesetzt ist.

Ansonsten:
Ich bin der festen Überzeugung, dass vor meinem Bildschirm ein Feature sitzt .

[tarkusch]

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

[tarkusch]

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]

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

[mk]

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

[Pikachu]

Die Definition deiner SDS enthält 2 Fehler:

SDjobnum muß 6stellig als "6s 0" definiert werden und MyIndikator muß als eigenständiges Feld (S) nach den Feldern der SDS definiert werden (da er nicht zur SDS gehört).

Siehe auch die Definition der SDS in ILE RPG.

[Fuerchau]

Falsche Syntax!

select F1, f2, ...
from filea
inner join fileb on filea.key = fileb.key
where x1 = ...