Dies ist für mich das Zeichen, dass die Art der Optimierung sehr stark vom vorhandenen Datenvolumen abhängt und man sich ggf. auf die STRSQL-Analyse im Debugmodus auch nicht immer verlassen kann.
Dieselbe Abfrage dauerte nämlich mit oder ohne Index über STRSQL nur wenige Sekunden.
Nicht vom Datenvolumen, sondern von der Datenzusammensetzung.
Seit SQE werden Informationen über die Datenzusammensetzung über den Statistiksmanager (Job, der tief im Betriebssystem läuft) gesammelt. Wird ein SQL ausgeführt, so werden die vorhandenen Zugriffswege basierend auf den gesammelten Informationen in den Statistik-Daten bewertet.

Binary Radix Tree Indices (ganz normale Zugriffswege) werden nur verwendet, wenn ca. 15% der Daten verarbeitet werden. Anderenfalls wird, sofern kein entsprechender EVI vorhanden ist, die Tabelle komplett verarbeitet.

Die CQE hat dagegen nur basierend auf Schätzungen ( = in der Where-Bedingung entspr. ca. 10% der Daten) optimiert.
Aber auch da (und dieses Problem hatten wir mehr als einmal, und auch in den unterschieldichsten Releases, das hat nichts mit 7.1 zu tun) wurde zum Zeitpunkt x der zuvor verwendete Zugriffsweg nicht mehr verwendet.

Was die Unterschiede zwischen ODBC und STRSQL betrifft, so könnten unterschiedliche Optimierungsziele (*FIRSTIO und *ALLIO) den Ausschlag geben. Das Optimierungsziel kommt dann zum Zug, wenn der Optimizer sich nicht im Klaren ist, ob ein Index-Zugriff oder bereits ein Table Scan erfolgen soll. Mit *FIRSTIO wird die Entscheidung zugunsten des Index ausfallen bei
*ALLIO zugunsten des Table Scans.
Ich vermute mal stark, dass Du beim ODBC Zugriff *ALLIO verwendest. STRSQL verwendet per Default *FIRSTIO. Das würde nämlich auch Deine Beschwerden darüber, dass die Resultsets immer komplett übertragen werden müssen erklären.
Das Optimierungsziel kann über OPTIMIZE FOR x ROWS in einem SELECT-Statement beeinflusst werden. Ersetzt man x durch eine kleine Zahl, so wird *FIRSTIO verwendet. Ersetzt man dagegen x durch eine große Zahl oder ALL wird *ALLIO verwendet.

Birgitta