dynamisches qmqry

[cbe]

oh, stimmt, das erste UPPER habe ich glatt überlesen :-(

Dann hast Du wohl tatsächlich keine andere Chance, als die 2 UPPER.

Trotzdem - vergiss die Verdopplung der Hochkomma nicht, falls Dein String solche enthält.

[Fuerchau]

Ausserdem ist der "Order by rrn(x)" nicht performanceförderlich.

Ein Like führt immer zum Tablescan wenn es denn keine weiteren Einschränkungen gibt.

[Robi]

vergiss die Verdopplung der Hochkomma nicht, falls Dein String solche enthält.

Ist bekannt, kommt aber nicht vor, BeforeTrigger verhindern das, schon wegen dem csv export.

Ausserdem ist der "Order by rrn(x)" nicht performanceförderlich.

Wenn das PF mit reusedltrcd(*no) erstellt wurde auch?

Ein Like führt immer zum Tablescan wenn es denn keine weiteren Einschränkungen gibt

Ja, stimmt. Daran habe ich bei der Performance-Bemerkung nicht gedacht.

Trotzdem ...
Auch wenn ich in diesem Fall die Unterscheidung GROSS/klein nicht brauche...

Ist das Verhalten 'normal'? einstellbar? oder ein Fehler?

Robi

[B.Hauser]

Wenn das PF mit reusedltrcd(*no) erstellt wurde auch?i

Der Order By wird dabei immer als letztes geprüft!
Sowohl der CQE als auch der SQE-Optimizer versuchen so schnell wie möglich an die Daten zu kommen.
Sofern ein oder mehrere Zugriffsweg verwendet werden können (um möglichst schnell an die Daten zukommen), ist es oft/meist besser diesen zu verwenden, die selektierten Daten temporär (z.B. in Hash-Tables) zu speichern und anschließend das Ergebnis zu sortieren.

Der Table-Scan (bzw. Table-Probe bei SQE) wird durch die Selektion über das LIKE-Prädikat erforderlich, da macht eine anschließende Sortierung des Ergebnisses den Kohl auch nicht mehr allzu fett.

Birgitta

[andreaspr@aon.at]

Ein Like führt immer zum Tablescan wenn es denn keine weiteren Einschränkungen gibt.

Tablescan ja, bei:

WHERE Upper (sp1) like Upper('XXX%')
WHERE sp1 like '%XXX%'

Jedoch bei folgenden Beispiel sollte kein Tablescan durchgeführt werden, falls ein Index mit dem Key vorhanden ist:

WHERE sp1 like 'XXX%'

(Zumindest ab 6.1)

lg Andreas

[Fuerchau]

Dies ist korrekt, manche SQL-Dialekte erlauben da einen "start with ...".