Zitat Zitat von B.Hauser Beitrag anzeigen
Ob der "gleiche" SQL-Cursor mehrfach ... in der gleichen Aktivierungsgruppe angesprochen wird, stellt kein Problem dar.
...
Was dabei allerdings zu berücksichtigen ist, ist, dass der FULL OPEN, also das erste Öffnen eines ODPs ein zeitaufwändiger Prozess ist. (Wesentlich zeitaufwändiger als eine Datei für native I/O zu öffnen!)
Deshalb sollte versucht werden die FULL OPENs bzw. die Anzahl der ODPs zu minimieren.

Birgitta
... in der gleich Aktivierungsgruppe gibt es jeden Cursor nur einmal, was bei mehrfachen Aufrufen aus unterschiedlichen Programmen entweder dazu führt, dass das zweite Programm diesen nicht neu öffnen kann (Cursorstate not valid), oder dem ersten Prozess den Cursor zerklopft.
Beim fetch würde sich das dann so auswirken, dass wenn die Programme abwechselnd lesen, jedes Programm nur jeden zweiten Satz zu sehen bekäme.

Das mit dem full open ist wieder mal nur fast richtig: im richtigen Leben braucht man sich nicht darum zu sorgen:
- bei sinnigem Index design dauert sowas ein paar Millisekunden
- die Datenbank macht ohnehin lazy closes, sodass es für die Laufzeit unerheblich ist, ob das 1 oder 3 millisekunden dauert, da die Zeiten für den fetch das dominieren.
Richtig wäre hier: man muss die Anzahl der fetch Operationen minimieren
- ein block fetch von 1000 records dauert so lange wie ein single fetch
- allerdings ist der positioned update soviel schneller als der searched update, dass selbiger dieses bei nicht read only Betrieb bei DB2/400 wieder reinholt.

D*B

PS: eine Ergänzung noch:
- cachen kann Wunder wirken!!!