Hallo Baldur,

der fetch first hat nach meiner Erfahrung ganz ähnliche Macken wie RRN(xxx), das keine Resultsets unterstützt. Es ist schon rein syntaktisch nicht möglich einen Subselect sinnig mit fetch first anzufassen, da der ja garkeine ORDER BY Klausel erlaubt. Aus gutem Grund ist dieser Zinnober auch kein Bestandteil des SQL Standards - und alleine schon deshalb würde ich es nicht verwenden, wenn es Standard werden sollte, ist das Risiko, dass sich das Verhalten ändert, einfach zu groß.

mfg

Dieter Bender

PS: Was die Geschwindigkeit angeht, ist optimize for x rows sicher schärfer, aber auch das geht zuweilen in die falsche Richtung. (Auch zu beobachten beim interaktiven SQL versus Programm; interaktiv optimiert meist für die ersten 20 Sätze, im Programm meist für das komplette ResultSet). Ansonsten ist das für DB2 ohne Belang, da nicht das open auf das ResultSet liest, sondern der fetch, mit dem ich seteurn kann, wie oft und wieviel gelesen wird.
Zitat Zitat von Fuerchau
Das wäre dann aber eine falsches Verständnis des fetch first.
Fetch first sollte erst dann wirken, wenn alle anderen Angaben vorher erledigt sind. Sprich das komplette Ergebnis incl. where, group, having und order und erst danach der fetch first.
Alle anderen Formen der Implementierungen machen für mein Verständnis überhaupt keinen Sinn.
Dies würde auch Birgittas Aussage bestätigen, da der fetch first eben nicht wesentlich schneller wird, da ja eben erst die gesamte Ergebnismenge sortiert werden muss.
Wie sonst sollte ich denn z.B. per SQL die Top 10 einer summierten Menge feststellen ?
In vielen Anwendungen, wie z.B. Windows habe ich sonst auf die Anzahl der Fetch wenig Einfluss. Die Eigenschaft MaxRecords der diversen Zugriffsmethoden wirken leider nicht immer.

Wie hat IBM denn nun implementiert ?