und wieder ein SQL SELECT Problem...

[a.wojcik]

Hallo *ALL,

ich habe ein SQL Phänomen festgestellt :
es erstelle in QTEMP 2 Tabellen, dann mach ich en SELECT :
select * from QTEMP/DATEI1 where XLIEFE in
(select LLIEFE from QTEMP/DATEI2)
Ergebnis korrekt, xx Sätze.
Beim nächsten Mal habe ich mich bei dem SELECT vertippt :
select * from QTEMP/DATEI1 where XLIEFE in
(select XLIEFE from QTEMP/DATEI2)
Eigentlich dürfte es nicht funktionieren - Feld XLIEFE gibt es in der DATEI2 nicht.
Aber Überraschung - ich bekomme Sätze angezaigt und zwar alle aus der DATEI1 !!!

Hat jemand schon so was gehabt ? Es ist doch nicht normal, oder ?

Gruß

[malzusrex]

Doch, ist es!

In einem Select kann ich ja auch Konstanten oder so mit angeben.
Wenn du den select abfeuerst, müsste eigentlich eine Ausschrift


Eine Unterabfrage mit einer Korrelation wurde eingegeben; es
fehlt jedoch das Qualifikationsmerkmal für:
kommen.
Die Kiste merkt schon , das das Feld nicht aus der Datei2 kommt. Und da du im den Select den Wert aus der 1 Datei mit angibst, ist die Bedingung erfüllt und er zeigt alle Sätze an

Gruß
Ronald

[a.wojcik]

OK, aber das gleiche in einer Produktivbibliothek funktioniert nicht ! Da bekomme ich sofort die Meldung, dass das Feld XLIEFE in der DATEI2 nicht vorhanden ist. Hier spielt der Eintrag in der SYSCOLUMN eine Rolle, in QTEMP Datei fehlt der.

Gruß
Andreas

[Fuerchau]

Da muss ich Roland zustimmen, da das Feld ja in Datei1 vorhanden ist.
Ein Subselect kann sich ja durchaus auf den übergeordneten beziehen:

select * from filea
where aaa in (select bbb from fileb where filea.x1 = fileb.y1)

Es macht natürlich wenig Sinn in der Selectliste Felder aus der übergeordneten aufzuführen. Aber Gründe (Berechnungen, Concat, o.ä.) kann ich mir schon vorstellen.
Daher ist das kein SQL-Fehler.

[a.wojcik]

mich wundert aber, dass das in einer Produktivumgebung nicht so ist - den identischen Befehl mit den identischen Dateien kann ich da nicht ausführen - und das finde ich korrekt.

[BenderD]

... meine DB2/400, MySQL, MS SQL Server und Oracle sehen das genauso wie Ronald und Baldur. Falls das bei Dir in einer bestimmten Konstellation anders ist, könnte das mit dem Zugriffsplan (Reihenfolge der Ausführung) abhängen, ist dann aber ein Bug und kein Feature.

D*B

[Fuerchau]

Ich würde da auch eine Meldung an IBM aufmachen, dass der SQL da nicht läuft:).