embedded SQL - close cursor

[B.Hauser]

Andere Frage noch:
In der SELECT-Anweisung wurden 2 Tabellen mit LEFT JOIN verbunden.
Jedes Dateifeld einzeln anzusprechen find ich bei großem Umfang nervig. Deshalt "*" und INTO in die externe DS, die ich mit der DDS beschrieben habe. Was aber wenn ich nun 2 Tabellen anspreche?

Dann definierst Du halt für jede Datei eine Datenstruktur und gibst sie beide beim Fetch an. Für die zweite Datei solltest Du außerdem eine Datenstruktur mit Indikator-Variablen verwenden, um festzustellen, ob NULL-Werte übertragen wurden.

C/EXEC SQL  Fetch CsrC1 into :DSFile1, :DSFile2 :DSIndFile2
C/END-EXEC 

Auch wenn es dir "nervig" erscheint Felder auszuwählen, SELECT * ist Gift für die Performance. Werden nur einzelne Felder ausgewählt können in einem Block wesentlich mehr Informationen eingelesen werden.

Birgitta

[Armin]

Danke Hr. Hauser für die Info.
Hat auch soweit geklappt. Nur die 3. DS übersteigt mein Verständnis.
Wie muss diese def. werden? Sollte es in der 2. Tabelle keinen passenden Satz geben würde die 2. DS nicht mit Blanks bzw. Nullen init.?

[B.Hauser]

Im 1. Schleifendurchlauf schließt der close und im 2. nicht mehr. Und was hat das ganze mit einem Datum zu tun?

Beim ersten Durchlauf wird der Cursor in der Regel vom System geschlossen, da der Query Optimizer mindestens 2 Durchläufe benötigt um sich auf einen Zugriffs-Pfad festzulegen.

Wenn der ODP (offener Zugriffs-Pfad) nicht geschlossen wird, was durch CLSSQLCSR = *ENDMOD am Ende des Moduls erfolgt. Wird der Optimizer bei jedem Durchlauf einen optimalen Zugriffs-Weg aus allen vorhanden Indices und geschlüsselten logischen Dateien ermitteln. Ist ein Zugriffs-Pfad bereits geöffnet entfällt dieser Overhead. Dies ist vorallem bei komplexen SQL-Statements von Vorteil.

Allerdings ... bleibt der Zugriffspfad geöffnet und verändern sich die Daten so sehr, dass eigentlich ein anderer Zugriffs-Pfad optimaler wäre, erfolgt KEINE Neu-Ermittlung! Da hilft dann nur die Aktivierungs-Gruppe zu schließen, den Job zu beenden oder grundsätzlich mit CLSSQLCSR zu arbeiten.

... Und übrigens sollte man nicht SELECT * verwenden, sondern die Felder, die man benötigt gezielt auswählen. Daduch können mit einem Block mehr Daten eingelesen werden. Zum anderen kann der Optimizer einen Zugriffs-Pfad ermitteln, der einen Index ONLY-Access ermöglicht, d.h. alle benötigten Informationen sind bereits in den Schlüssel-Werten hinterlegt und ein zusätzlicher Zugriff auf den Datensatz ist nicht erforderlich.

Birgitta

[BenderD]

Hallo,

hier muss man Cursor und ODP auseinanderhalten.
Im Programm habe ich einen Cursor, dessen öffnen zur neu Psoitionierung führt und desse Status nur zwichenn open und close wechseln kann; alles andere verursacht Fehler.
Die Datenbank kennt einen ODP, den sie besser offen lässt, da er meist nochmal gebraucht wird und der dann Sperren auf die Tables hat.
Das ganze CLOSQLCSR Gedönse wirkt auf Cursor und nicht auf ODPs, auch wenn es zuweilen anders ausschauen mag!
ODPs, die keiner benutzt, werden von SQL automatisch geräumt, wenn sie von SQL benötigt werden. Dasselbe erreicht man auch mit ALCOBJ CONFLICT(*RQSRLS) wenn einen das irgendwann mal stört.

@Birgitta:
Mit dem neu eröffnen von ODPS in laufenden Programmen habe ich unter V5R3 schon positive Überraschungen erlebt (nach anlegen eines Index)
Wenn Daten komplett über einen Zugriffspfad geholt werden können, dann ist meist mit dem Design was faul, ausser bei Where in Subselect Konstrukten, wo select * eh' nicht geht.

mfg

Dieter Bender