optimize for n rows:
Alle meine Versuche, die selben Antwortzeiten bzgl. des 1. Satzes wie mit STRSQL zu erreichen, sind kläglich gescheitert.
Egal ob ich ODBC oder embedded SQL verwende, den Weg, den STRSQL geht kann ich leider nicht nachvollziehen.

Ein SQL in STRSQL ist häufig sehr schnell, die Debug-Nachrichten werden untersucht, ggf. angewendet.
Spätestens im embedded SQL läuft da irgendwas anders, so dass diese Antwortzeiten einfach nicht erreichbar sind.
Alle dynamischen SQL-Interfaces oder Abfragen (dazu gehören natürlich auch interaktives SQL oder embedded dynamic SQL) werden per Default mit dem Optimierungsziel *FIRSTIO ausgeführt. Es wird also so optimiert, dass die erste Seite so schnell wie möglich ausgegeben wird.

Statisches Embedded SQL wird dagegen mit dem Optimiuerungsziel *ALLIO ausgeführt. Es wird also so optimiert, dass die komplette Abfrage so schnell wie möglich ausgeführt wird.

Diese Unterscheidung ist vor allem dann wichtig, wenn es darum geht einen Index-Zugriff oder einen Table Scan zu verwenden. *FIRSTIO tendiert dazu doch lieber einen Index zu nehmen, während *ALLIO zum Table Scan tendiert.

Um beim intraktiven SQL mit dem gleichen Optimierungsziel wie beim Statischen embedded SQL zu arbeiten, sollte im interaktiven SQL am Ende des Select-Statements OPTIMIZE FOR *ALL ROWS angegeben werden.

Noch besser ist es, Du gibts im embedded SQL das Optimierungsziel immer am Ende eines SELECT-Statements an und übernimmst dann dieses Ziel, wenn Du die Abfrage interaktiv ausführst.


@Dieter
FORCE_JOIN_ORDER default *NO favorisiert SQE
IGNORE_DERIVED_INDEX default *NO favorisiert CQE
IGNORE_DERIVED_INDEX war deshalb auf *NO geblieben, um (voraussehbare) Probleme mit der SQE zu minimieren, bzw. um zu verhindern dass einem wichtige Zugriffswege unter den Füßen weggezogen wurden. Da die meisten alten Anwendungen logische Dateien mit SELECT/OMIT-Anweisungen haben, wurden relativ wenige Abfragen mit der SQE ausgeführt.

Nur wer eine einigermaßen saubere SQL-Datenbank mit Referentiellen Integritäten und sauberen SQL-Indices hat, hat das Vergnügen sich mit der SQE herumzuschlagen. (Deshalb auch mein Kommentar von gestern, dass in den meisten Fällen, in denen auf die SQE geschimpf wurde und wird, die CQE die Abfragen ausführt.)

Das böse Erwachen wird für viele mit Release 6.1 kommen. Mit Einführung der Derived Indices unter Release 6.1 hat IBM beschlossen den Default-Wert für IGNORE_DERIVED_INDEX in der QAQQINI in der Bibliothek QSYS von *YES auf *NO zu ändern. Wurden also die DDS beschriebenen logischen Dateien nicht durch Derived Indices ersetzt werden bei vielen Abfragen wichtige Zugriffwege nicht mehr gezogen.

Übrigens die SQE ist mit Release 6.1 abgeschlossen, d.h. was jetzt nicht von der SQE verarbeitet werden kann, wird es auch nie werden können.

@Baldur
Die CQE wird genauso verschwinden wie die /36-Umgebung und der RPGIII-Compiler ... also uns noch einige Zeit erhalten bleiben.

Birgitta