Wie immer hat sich der Optimizer mal wieder verändert:
Beispiele:
Tabelle mit CHAR(3)-Feld

Select blabla
from MyTable where Feld = 123

Sicherlich ein Programmierfehler, da 123 in Hochkomma gehört.
Aber bis V6R1 wurde daraus intern vom Optimizer:

where Feld = cast(123 as char(3))

Vorteile:
Wenn ein Index vorhanden ist wurde dieser genommen.
Wenn "Feld" irgendwas anderes enthielt war das kein Problem.

Neu Ab V7R1:
where cast(Feld as decimal(3, 0)) = 123

Gravierende Nachteile:
Keine Verwendung eines Indexes da ja nun das Feld gecastet wird!
Absturz des SQL's wenn "Feld" nicht numerisch ist!

Da solche "Tippfehler" leider häufiger vorgekommen sind und bisher unkritisch waren sind plötzlich einige Programme zu kritischen geworden da diese unerwartete Fehler bekommen.

Des weiteren sind viele SQL's neu zu optimieren, da bis V6R1 die Laufzeit sehr gut war sich dies aber ab V7R1 zum Teil dramatisch verschlechtert hat.
Dies betrifft natürlich keine simplen sondern wie immer nur die komplexeren SQL's.
Nach Erstellen diverser Indizes und Behebung obiger SQL's ist alles wieder im grünen Bereich.

Leider gibt es bestimmt noch einige Programme, die obige Fehler aufweisen. Diese scheinen bisher aber unkritisch zu sein. Vor allem, wenn das Quellfeld tatsächlich ausschließlich numerische Werte enthält.