View Full Version : embedded SQL - close cursor
Das Komma zwischen Variable und Anzeigervariable in der Fetch-Anweisung ist zu viel
C/EXEC SQL
C+ FETCH NEXT FROM AUFGEScursor INTO :AUFGESsql, :FESTCKS1sql :AnzeigerSQL
C/END-EXEC
Das "," ist weg, aber der Fehler -305 bleibt!
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
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.
Hast du mal versucht eine weitere Anzeigervariable für deine erstes Feld einzubauen?
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, ...
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 (http://www.redbooks.ibm.com/abstracts/sg245402.html?Open)
Modernizing IBM eServer iSeries Application Data Access - A Roadmap Cornerstone (http://www.redbooks.ibm.com/abstracts/sg246393.html?Open)
Für Fortgeschrittene gibt es dann auch noch:
Embedded SQL Programming (http://publib.boulder.ibm.com/infocenter/iseries/v5r3/ic2924/index.htm?info/rzajp/rzajpkickoff.htm)
Birgitta
:) 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!
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