- das war bisher einer der elegantesten Workarounds im Problemfall an der SQE vorbei zu kommen.
- STRSQL: hast du optimize for 1 rows direkt beim select angegeben?
ansonsten wird interaktiv meist CPU schonend gearbeitet (betrifft auch embedded SQL im 5250) und oft ist da auch noch caching im Spiel und interaktiv ist immer read only und blocken ist erlaubt. Wenn du dann immer noch Laufzeitdifferenzen hast, dann wären die Diagnostics des Optimizers bezüglich der Ausführung noch interessant, am Besten per DBMON ermittelt.

D*B

PS: wobei ich immer noch glaube, dass du am leuchten in den Augen noch arbeiten musst, wenn du "s la vache qui rit engine" vor dich hin murmelst während der Optimizer den optimalen Zugriffsweg zusammenbraut.

Zitat Zitat von Fuerchau Beitrag anzeigen
IGNORE_DERIVED_INDEX = *NO (*DEFAULT) und LF mit Select/Omit zwingt zu 99,99% in die CQE.

PS:
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.