embedded SQL - close cursor

[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