embedded SQL - close cursor

[Armin]

Also das funktioniert einfach nicht! Weiterhin SQLCOD -501
FILEselect = 'select * ' +
'from FILE1 left join FILE2 on ' +
'BBELE = STBELE and BPOSI = STPOSI and ' +
'STSTAT = 4 ' +
'where BTEIL<>''E'' and ' +
'BKENN = '':WsGeb'' and BLIEW <= '':WsWoche'' ' +
'order by BKUND, BLIEW' ;
declare FILEcursor CURSOR for FILEselect
open FILECursor
FETCH NEXT FROM AUFGEScursor INTO :FILE1ds, :FILE2ds

Zur Anzeigervariablen:
Entspricht -1 dem SQLCOD 100?
Der Wert -2 entsteht wenn die 2. DS zu wenig Felder hätte?

[JonnyRico]

Nein, weil was du machst ist auch ein Mischmasch aus Dynamisch und Statisch.
Versuch es doch einfach mal mit:

declare FILEcursor CURSOR for 
select * from FILE1 left join 
FILE2 on BBELE = STBELE and BPOSI = STPOSI and STSTAT = 4 
where BTEIL<>'E' and BKENN = :WsGeb and BLIEW <= :WsWoche
order by BKUND, BLIEW

open FILECursor
FETCH NEXT FROM AUFGEScursor INTO :FILE1ds, :FILE2ds 

[Armin]

Danke für deine Geduld, aber auch so klappt´s nicht.

C/EXEC SQL
C+ declare AUFGEScursor CURSOR for
C+ select * from AUFGES left join
C+ FESTCKS1 on BBELE = STBELE and BPOSI = STPOSI and STSTAT = 4
C+ where BTEIL<>'E' and BKENN = :WsGeb and BLIEW <= :WsWoche
C+ order by BKUND, BLIEW
C/END-EXEC

C/EXEC SQL
C+ OPEN AUFGEScursor
C/END-EXEC

C/EXEC SQL
C+ FETCH NEXT FROM AUFGEScursor INTO :AUFGESsql, :FESTCKS1sql, :AnzeigerSQL
C/END-EXEC

SQLCOD ist jetzt -305 und AnzeigerSQL = 0
Nachricht . . . : Anzeigervariable erforderlich.
Ursache . . . . : Eine Anweisung FETCH, eine eingebettete Anweisung SELECT,
eine Anweisung CALL, SET oder VALUES INTO hatte einen Nullwert zur Folge,
für Host-Variable &2 wurde jedoch keine Anzeigervariable angegeben. Die
relative Position der Host-Variablen in der Klausel INTO oder der
Parameterliste ist &1. Ist der Name der Host-Variablen *N, wurde ein
SQL-Deskriptorbereich (SQLDA) angegeben.
Fehlerbeseitigung: Eine Anzeigervariable angeben und das Programm erneut
vorumwandeln.

Nach der Compilerliste schein er aber die Variablen in der Select-Anweisung zu nehmen.

[JonnyRico]

Das Komma zwischen Variable und Anzeigervariable in der Fetch-Anweisung ist zu viel

[Armin]

C/EXEC SQL
C+ FETCH NEXT FROM AUFGEScursor INTO :AUFGESsql, :FESTCKS1sql :AnzeigerSQL
C/END-EXEC
Das "," ist weg, aber der Fehler -305 bleibt!

[JonnyRico]

mmm...weiß nicht aber das FETCH NEXT stört mich noch. Wenn du mehrere Druchläufe also mehrere Sätze "fetchen" willst, dann machst du das mit ner Schleife

C dow 1=1

C/EXEC SQL
C+ FETCH AUFGEScursor INTO :AUFGESsql, :FESTCKS1sql :AnzeigerSQL
C/END-EXEC

*Kein Satz (mehr) gefunden
C if SQLCOD=100 Or SQLCOD < *Zeros
C leave
C endif
C enddo
C/EXEC SQL
C+ Close AUFGEScursor
C/END-EXEC

[Armin]

C/EXEC SQL
C+ declare AUFGEScursor CURSOR for
C+ select * from AUFGES left join
C+ FESTCKS1 on BBELE = STBELE and BPOSI = STPOSI and STSTAT = 4
C+ where BTEIL<>'E' and BKENN = :WsGeb and BLIEW <= :WsWoche
C+ order by BKUND, BLIEW
C/END-EXEC

C/EXEC SQL
C+ OPEN AUFGEScursor
C/END-EXEC

/Free
Dou SQLCOD = 100 ; // 1)EOF
/End-Free

C/EXEC SQL
C+ FETCH NEXT FROM AUFGEScursor INTO :AUFGESsql, :FESTCKS1sql :AnzeigerSQL
C/END-EXEC
/Free
If SQLCOD <> 100 ; // 2)
//-------------------------------------------------------------------------
Druckausgabe
//-------------------------------------------------------------------------
Endif ; // 2)
Enddo ; // 1)

Hab den Namen AnzeigerSQL jetzt schon verkürzt wegen der Zeilenlänge. Bleibt aber bei dem Fehler.

[JonnyRico]

Hast du mal versucht eine weitere Anzeigervariable für deine erstes Feld einzubauen?

[Fuerchau]

Das ist der Nachteil des SELECT * ...
Für jedes Feld, dass in der Datei FESTCKS1 definiert ist, benötigst du eine Anzeiger-Variable !
Führe besser jedes tatsächlich benötigte Feld auf, dann weißt du auch, für welche Felder du Anzeiger benötigst.
Der Grund ist der LEFT JOIN, der besagt, dass in der Datei FESTCKS1 nicht unbedingt ein Satz vorhanden sein muss. In diesem Fall wird für jedes Feld dieser Datei ein NULL-Wert gemeldet. Daher benötigst du eben auch für jedes Feld einen Anzeiger.

Im FETCH sind dann die Felder genauso einzeln aufzuführen, wobei die Felder mit Anzeiger als Paar angegeben werden müssen:

fetch mycursor into
: FELDA1, : FFELDA2, ...
: FELDB1 : ANZB1, :FELDB2 : ANZB2, ...

[B.Hauser]

Hallo Armin,

eine Anzeiger-Variable ist ein Integer-Feld, definiert mit 5I 0 in RPG. Du solltest allerdings für jedes Feld in Deiner Datei einen entsprechenden Indikator haben. Deshalb mein Vorschlag eine Datenstruktur zu bilden mit den entsprechenden Variablen.

Ansonsten solltest Du Dir vielleicht einmal ein bißchen Literatur über Embedded SQL reinziehen.
In den folgenden Redbooks (allerdings nur auf Englisch) findest Du ganz gute Beispiele:
Who Knew You Could Do That with RPG IV? A Sorcerer's Guide to System Access and More
Modernizing IBM eServer iSeries Application Data Access - A Roadmap Cornerstone

Für Fortgeschrittene gibt es dann auch noch:
Embedded SQL Programming

Birgitta

[Armin]

Der nackte Wahnsinn! Super, das war´s!
Jetzt wär´s nur noch schön, wenn ich´s verstehn tät.
Die Daten, die ich jetzt reinkrieg, haben Füllung in der Primär- und in der Sekundärdatei.

Wann ist dann eigentlich dyn. SQL sinnvoll?

Mehrere Sätze auf einmal können doch eingelesen werden. Macht das im RPG Sinn?

Vielen Dank. Ihr alle seid echt super!

[B.Hauser]

Wann ist dann eigentlich dyn. SQL sinnvoll?

Mehrere Sätze auf einmal können doch eingelesen werden. Macht das im RPG Sinn?

Dynamisches SQL muss verwendet werden, wenn Tabellen(Dateien) oder Schemata (Bibliotheken) variabel verwendet werden müssen. Dies ist in statischem SQL nicht möglich.

Ebenso muss dynamisches SQL verwendet werden, wenn aus einer Datei unterschiedliche Felder selektiert werden, also einmal z.B. Bestell-Nr. und Kunden-Nr. und das nächste Mal Kunden-Nr und Liefertermin usw. Allerdings muss in diesem Fall in RPG mit eine SQL Descriptor Area (SQLDA) gearbeitet werden und das ist reichlich kompliziert.

Alles andere habe ich bisher mit statischem SQL hinbekommen, egal, ob es unterschiedliche Auswahl-Felder oder -Bereiche waren oder ob es verschiedene Listen waren oder ob unterschiedliche Sortierungen erfordelich waren.

Der Vorteil von statischem SQL ist, dass bereits zur Compile-Zeit die SQL-Syntax geprüft wird. Bei dynamischem SQL kann die Syntax-Prüfung und die Konvertierung eines Text-Strings in ein ausführberes SQL-Statement erst zur Laufzeit erfolgen, was Performance-Einbußen mit sich bringt.
Weiterhin wird bei statischem SQL der Access Plan im Programm-Objekt gespeichert und beim nächsten Durchlauf zum Erstellen des Zugriffs-Pfades verwendet. Beim Dynamischen SQL wird kein Access Plan im Programm-Objekt gespeichert.

Mit embedded SQL können natürlich auch mehrere Sätze auf einmal eingelesen werden, entweder in eine Mehrfach-Datenstruktur oder ab Release V5R3M0 auch in eine Array-Datenstruktur.

Birgitta