Embedded SQL - keine Daten bei 2. Aufruf

[BenderD]

- erstmal siehst du im Joblog, dass da 6507 Sätze eingefügt wurden
- davor ist nochwas mit Datenumsetzung, was du nochmal prüfen solltest
- wenn dein interaktives Statement da was anderes liefert, dann musst du das Stück für Stück analysieren.
- die Meldungen Zugriffspfad erstellt solltest du nochmal genauer ansehen, inklusive der vorhergehenden, die die jeweilige Datei betreffen, da wirst du das finden, was hier Zeit braucht und wie man es schneller machen kann (und oft logische Fehler in der Verknüpfung), den ganzen open close Zinnober, den kannst du getrost vergessen, das ist Pillepalle im Vergleich zu Zugriffspfad Aufbau!!!!!!!

BTW: deinen ursprünglichen Fehler hättest du im Joblog bei dieser Vorgehensweise in 10 Minuten gefunden!!!
Mit open close hat der wohl nix zu tun, sondern mit dem jeweiligen Inhalt von Programmvariablen (SQL ist steng typgebunden, RPG eine Huddelprogrammiersprache, die im Zweifel jeden Schlunz in Variablen reinfummeln lässt). Beim Beenden des Jobs und Neuaufruf wird frisch initialisiert angefangen, bei erneutem Aufruf im selben Job bleibt ein ILE Modul aktiviert (ausser ACTGRP *NEW) - das ist vergleichbar zum verlassen OPM Programm ohne LR

D*B

[Tobse77]

Danke für die Tipps. Da ich lediglich die Vorteile von RPGIV gegenüber RPG400 nutze, aber nicht im ILE-Konzept programmiere, bin ich hier sehr unerfahren.

- Die eingefügten Sätze sollten eigentlich 6532 sein, aber die Suffix-TNr lässt er ja weg.
- Das mit der Datenumsetzung hat Ursachencode 8 (Die Zieltabelle der Anw. INSERT ist keine SQL-Tabelle) <- stimmt; ist DDS!!
- bzgl. der Meldungen mit dem Zugriffspfad habe ich gesehen, dass ein temp. Zugriffspfad erstellt wurde und dabei kein "Parallelismus" verwendet wurde ... ich schätze mal, das ist gut so :-)

Die interaktive SQL-Anweisung habe ich nun auch einmal im Debug-Modus laufen lassen:
> strdbg
> strsql
Aktuelle Verbindung besteht zur relationalen Datenbank S6599E0C.
Abfrageoptionsdatei kann nicht abgerufen werden.
Abfrageoptionsdatei kann nicht abgerufen werden.
Der Zugriffsplan der Abfrage wurde erneut erstellt.
Abfrageoptionsdatei kann nicht abgerufen werden.
****: Debug-Nachrichten des Optimierungsprogramms für Abfrage werden
gestartet.
Abfrageoptionsdatei kann nicht abgerufen werden.
Abfrageoptionsdatei kann nicht abgerufen werden.
Temporäre Datei für Datei MITEM erstellt.
Der Zugriffsplan der Abfrage wurde erneut erstellt.
Alle Zugriffspfade wurden für Datei V#VSTA00 berücksichtigt.
Zusätzliche Ursachencodes für Zugriffspfad verwendet.
Zugriffspfad für Datei *QUERY0004 erstellt.
Datei V#VSTA00 in Verknüpfungsposition 1 verarbeitet.
Datei *QUERY0004 in Verknüpfungsposition 2 verarbeitet.
Datei V#TAMH00 in Verknüpfungsposition 3 verarbeitet.
Datei V#TALI00 in Verknüpfungsposition 4 verarbeitet.
Abfrageoptionsdatei kann nicht abgerufen werden.
****: Debug-Nachrichten für Abfrage werden beendet.
ODP erstellt.
Blockung für Abfrage.
>> enddbg

Schlau geworden bin daraus allerdings nicht :-(

Weiß immer noch nicht, weshalb der Left Outer Join nicht so funktioniert, wie er sollte.

[BenderD]

- das mit dem Parallelismus bedeutet, dass es schneller geht, aber mehr Strom braucht
- für die Differenzen wirst du dich schon mit deiner where klausel beschäftigen müssen, die sieht für mich eh suspekt aus

D*B

[Tobse77]

Hallo,

habe den Fehler gefunden !!
Wie Dieter schon vermutet hat, liegt es nicht am Left Outer Join, sondern an der Where-Anweisung !!
In den beiden SQL-Statements
And Case When :imhptgr <> ' ' Then :imhptgr Else mi1v22 end
= mi1v22
und
And Case When :iuland <> ' ' Then :iuland Else mi1v19 end = mi1v19

frage ich mit mi1v22 (Marken-Gruppe der TNr) und mi1v19 (Ursprungsland der TNr) Felder ab, die sich nicht in der führenden Datei (Alias: Statistik) befinden, sondern in der Datei MITEM (Teilestamm). Und das ist genau die Datei, welche die Suffix-Teile nicht beinhaltet !!

Soweit die Fehlerergründung...

Jetzt stehe ich allerdings vor der Frage, wie ich dies beheben kann. Die beiden Case-Anweisungen darf ich nicht einfach eliminieren, da der Benutzer seine Auswertung sonst nicht mehr über Marken-Gruppe oder Ursprungsland selektieren kann.
Gibt es in SQL eine Möglichkeit, die es mir erlaubt um diese beiden CASE-Anweisungen herum eine Bedingung zu definieren, so dass die CASE-Anweisung nur dann greift, wenn der Satz in der Datei MITEM gefunden wurde?? Vermutlich aber wohl nur wenn ich die Daten satzweise einlese, oder?

Falls jemand eine zündende Idee hat, bitte her damit :-)

[BenderD]

And Case When :imhptgr <> ' ' Then :imhptgr Else
coalesce(mi1v22, ' ')
end = coalesce(mi1v22, ' ')

oder auch:

(And Case When :imhptgr <> ' ' Then :imhptgr Else mi1v22 end
= mi1v22
or mi1v22 is null)

D*B

Hallo,

habe den Fehler gefunden !!
Wie Dieter schon vermutet hat, liegt es nicht am Left Outer Join, sondern an der Where-Anweisung !!
In den beiden SQL-Statements
And Case When :imhptgr <> ' ' Then :imhptgr Else mi1v22 end
= mi1v22
und
And Case When :iuland <> ' ' Then :iuland Else mi1v19 end = mi1v19

frage ich mit mi1v22 (Marken-Gruppe der TNr) und mi1v19 (Ursprungsland der TNr) Felder ab, die sich nicht in der führenden Datei (Alias: Statistik) befinden, sondern in der Datei MITEM (Teilestamm). Und das ist genau die Datei, welche die Suffix-Teile nicht beinhaltet !!

Soweit die Fehlerergründung...

Jetzt stehe ich allerdings vor der Frage, wie ich dies beheben kann. Die beiden Case-Anweisungen darf ich nicht einfach eliminieren, da der Benutzer seine Auswertung sonst nicht mehr über Marken-Gruppe oder Ursprungsland selektieren kann.
Gibt es in SQL eine Möglichkeit, die es mir erlaubt um diese beiden CASE-Anweisungen herum eine Bedingung zu definieren, so dass die CASE-Anweisung nur dann greift, wenn der Satz in der Datei MITEM gefunden wurde?? Vermutlich aber wohl nur wenn ich die Daten satzweise einlese, oder?

Falls jemand eine zündende Idee hat, bitte her damit :-)

[Tobse77]

SPITZE Dieter !!! :-)

Genau so funktioniert's !!
Hatte mir schon mit einer 2. SQL-Anweisung in Abhängigkeit von den Eingabefeldern beholfen, aber dieser Weg ist natürlich weitaus eleganter - und wohl auch effizienter.

VIELEN DANK !!