Zitat Zitat von Fuerchau Beitrag anzeigen
Wie oben bereits beschrieben, ist STRSQL generell kein Vergleich zu embedded SQL.
Ich habe auch schon bei STRSQL mit verschiedenen OPTIMIZE-Klauseln gearbeitet, komme aber immer zum selben Ergebnis.

Einen Punkt habe ich aber doch schon mal gefunden.
Auch beim Group By wird versucht über einen Index zu gehen.
da gibt es allerdings Situationen wo das ungünstiger ist, als den Group By im Speicher bzw. auf Datenkopien des Queryoptimizers machen zu lassen.
Um die Indexverwendung eines Group By auszuschließen, reicht ein berechnetes Feld zu verwenden:

select coaleasce(f1, f1) f1, coaleasce(f2, f2) f2, sum(fx) fx
from mytable
where .....
group by coaleasce(f1, f1), coaleasce(f2, f2)

Die Daten werden durch die Whereklausel schnell gefunden, aber der Group By kann keinen Index verwenden.
Dies zwingt den Optimizer ggf. dazu temporäre Ergebnisse zu generieren oder einfach nur den Speicher zu bemühen.
Auch wenn man es kaum glaubt, es machte schon die eine oder andere Abfrage erheblich schneller.
Ggroup by ist drin mit ca. 30 Feldern. Es werden Lieferscheine gruppiert und da sind u.a. die Zahlungsbedingungen dabei, deshalb so viele Felder.
Dies ist das erste Mal wo ich derartige Probleme habe. Wir arbeiten viel mit SQLRPG Programmen und es gab nie Probleme. Wenn mal ein SQL langsam war, dann lag es meistens am fehlenden Index und der fehlte dann auch im STRSQL. So ist es echt schlecht.