Zitat Zitat von BenderD Beitrag anzeigen
... es gibt immer eine Antwort und die ist in diesem speziellen Fall unmittelbar aus den beiden Joblogs ersichtlich. Wie Du dieses SQL Statement mit einem "altbackenen READE" ablösen willst, das ist mir ein wenig schleierhaft, aber sei#s drum.
Was Dein SQL Statement angeht, ein where KONSTANTE in (select ...), das ließe sich auch in einen inner join auflösen, der nur das mitnimmt, was mit der KONSTANTE matched.
D*B
Passiert zwar selten, aber zur Abwechslung bin ich mal mit Dieter einer Meinung.

I.d.R. performen Inner-Joins (mit und ohne Sub-Select oder CTE) besser als Sub-Selects in WHERE-Bedigungen. Der Query Optimizer kann nämlich in diesen Fällen ggf. die Reihnfolge der Verknüpfungen ändern. Bei Sub-Selects in den WHERE-Bedinungen zwingt man dem Optimizer die Reihenfolge auf.
In Deinem Beispiel kommt noch erschwerend dazu, dass der Sub-Select mit einer Konstanten vergleicht. Damit nimmt man dem Optimizer auch noch die Möglichkeit einen Index zu verwenden.

Führe ich das mit einer 5250 Emulation über Client Access aus, habe ich das Ergebnis in 4-5 Sekunden. Rätsel über Rätsel
Versuch noch mal eines: Füge in Deinem Cursor am Ende des SELECT statements mal folgendes ein:
OPTIMIZE FOR 10 ROWS.

Wenn Client Access schnell ist und embedded SQL langsam, so liegt das meist am Optimierungsziel. Dynamische SQLs (u.a. auch STRSQL oder Client Access) werden mit Optimierungsziel *FIRSTIO optimiert, während statisches SQL mit *ALLIO optimiert wird.
Das heißt, dass bei *FIRSTIO im Zweifel noch ein Index verwendet wird, während bei *ALLIO im Zweifel eine Table Scan ausgeführt wird.
Normalerweise ist die Sachlage eindeutig, aber in bestimmten Situationen (in die Du u.U. gerade gestolpert bist), kann das beträchtliche Auswirkungen haben.
Mit OPTIMIZER FOR x ROW kann das Optimierungsziel beinflusst werden, d.h. x=kleine Zahl --> *FIRSTIO, x=große Zahl oder ALL --> *ALLIO

Birgitta