Fehler oder works as designed??

Folgende DDL:
C REATE TABLE DBA.CURSORTEST (FELD1 DEC(1), FELD2 DEC(1), FELD3 DEC(1))
IN DBA.TS;

I NSERT INTO DBA.CURSORTEST VALUES (1, 1, 5);
I NSERT INTO DBA.CURSORTEST VALUES (1, 2, 5);
I NSERT INTO DBA.CURSORTEST VALUES (1, 3, 5);
I NSERT INTO DBA.CURSORTEST VALUES (1, 4, 5);

C REATE UNIQUE INDEX DBA.XCURSORTEST ON DBA.CURSORTEST
(FELD1, FELD2, FELD3);

folgende Logik im Programm:
D ECLARE C-UB CURSOR FOR
S ELECT FELD1, FELD2, FELD3
FROM DBA.CURSORTEST
WHERE FELD1 = :HF1
ORDER BY FELD2

Zugriff über den Index…Es gibt im Explain keinen Sort-Step, daraus schliesse ich, dass die Ergebnismenge nicht "materialisiert" wird, sondern dynamisch nachgefetched wird.

Fetch erster Satz Into HF1, HF2, HF3, NOOP,
Fetch zweiter Satz Into HF1, HF2, HF3.

Mit diesem HF3 := HF3 Minus! 1
U PDATE DBA.CURSORTEST
SET FELD3 = :HF3
WHERE FELD1 = :HF1
AND FELD2 = :HF2

Fetch dritter Satz, NOOP
Fetch vierter Satz, NOOP

alles ok

aber nun:
D ECLARE C-UB CURSOR FOR
S ELECT FELD1, FELD2, FELD3
FROM DBA.CURSORTEST
WHERE FELD1 = :HF1
ORDER BY FELD2

Zugriff über den Index… Es gibt im Explain keinen Sort-Step, daraus schliesse ich, dass die Ergebnismenge nicht "materialisiert" wird, sondern dynamisch nachgefetched wird.

Fetch erster Satz Into HF1, HF2, HF3, NOOP,
Fetch zweiter Satz Into HF1, HF2, HF3.

Mit diesem HF3 := HF3 plus! 1
U PDATE DBA.CURSORTEST
SET FELD3 = :HF3
WHERE FELD1 = :HF1
AND FELD2 = :HF2

Fetch dritter Satz bringt den 2 (aktualisierten) Satz nochmal, NOOP
Fetch vierter Satz bringt den 3 Satz, NOOP
Fetch fünfter Satz bringt den 4 Satz, NOOP

normal?? OK, man könnte argumentieren, ich manipuliere mit meinem Update die Resultmenge und durch den dynamischen Fetch bekomme ich den wieder (aber warum? Den Satz hatte ich gerade und der Fetch soll mir den nächsten geben…)

Aber es kommt (m.E.) noch doller …
Ich lege den Index nur mit Feld1, Feld2 neu an, das Programm wird nur neu gebunden…

D ECLARE C-UB CURSOR FOR
S ELECT FELD1, FELD2, FELD3
FROM DBA.CURSORTEST
WHERE FELD1 = :HF1
ORDER BY FELD2

Zugriff über den Index…Es gibt im Explain auch hier keinen Sort-Step, daraus schliesse ich, dass die Ergebnismenge auch hier nicht "materialisiert" wird, sondern dynamisch nachgefetched wird.

Fetch erster Satz Into HF1, HF2, HF3, NOOP,
Fetch zweiter Satz Into HF1, HF2, HF3.

Mit diesem HF3 := HF3 Plus!! 1
U PDATE DBA.CURSORTEST
SET FELD3 = :HF3
WHERE FELD1 = :HF1
AND FELD2 = :HF2
Fetch dritter Satz, NOOP
Fetch vierter Satz, NOOP

alles ok … Warum bekomme ich hier nicht auch den aktualisierten Satz nochmal?
Ist das richtig/kann es richtig sein, dass das Ergebnis eines Programms vom Index-Design abhängig sein soll?

Wir haben hier jetzt Grundsatzdiskussionen. Ähnliche Tests haben ergeben, dass das unter SQLServer2005 genauso läuft; unter Oracle wie von mir erwartet anders…

Was sagt ihr?

Danke
Alexander

PS: sorry für die Verstümmelung der SQLs, aber sonst wirds nicht gepostet …