Unerwarteter SQL-Fehler in V6R1

[BenderD]

die spannende Frage läuft dann darauf hinaus, ob die where Bedingungen in der View vor den Where Bedingungen der Abfrage vorrangig sind - das wird möglicherweise zum Feature erklärt...
D*B

[Fuerchau]

Nun ja, was hätte dann ein Casting in einer View für einen Sinn, wenn ich das Ergebnisfeld dann nicht in einer Where-Klausel verwenden darf.

Ich muss mal ausprobieren, ob das auch mit einem Cast auf Date zum Problem wird.

Ich mache das sehr häufig in CTE's da die besagten Altanwendungen ein Datum meist numerisch speichern.
Für die Clients gibts dann entsprechende Views, die nun mal mit V5R4 laufen.

@Dieter
Wie gesagt, Select * from MyView klappt ohne Probleme.

[BenderD]

... du darfst es ja verwenden, aber...
die View ist (wie ein CTE auch!!!) lediglich ein abgespeichertes SQL Statement und wird in Verbindung mit dem Select auf die View verwendet, um die Ergebnismenge zu berechnen. In deinem Fall (den man durch einen Index sogar noch forcieren kann!!!) wird in der Zugriffsstrategie die where Klausel der Abfrage vorgezogen (mit automatischem Cast), weil die die höhere Selektivität hat (was nicht einmal unvernünftig ist).
Erzwingen könnte man die Reihenfolge durch ein Fuction, die kann die Query engine nicht invertieren.

Dieter

[Fuerchau]

Bisher ist das ja auf V5R4 nicht als Fehler aufgefallen.
Wenn es auf V5R4 läuft und wie Birgitta sagt, auf V7R1 auch, so sollte es auch auf V6R1 funktionieren.

Ich denke, da liegt ein Fehler beim Optimizer vor.

[Fuerchau]

Ich habe nun von der IBM einfach nur die Meldung bekommen, dass in einem Satz ungültige Daten vorliegen.
Dass wusste ich ja auch, deshalb werden diese ja per View bereits ausgeschlossen (nämlich die nicht numerischen und zu langen).

Nun wurde eine Beispieltabelle gefordert, die ich dann auch bereitgestellt habe.
Bei einem Test vor dem Versenden an die IBM trat der Fehler plötzlich nicht mehr auf ???

Nach weiterer Analyse habe ich dann festgestellt:
Über das Feld existiert auf dem Original ein Index !
Legt man also den Index an, kommt der Fehler, löscht man den Index wieder kann man den Select auf die View mit Where-Klausel ausführen.

Ich erwarte von SQL, dass unabhängig von der Existenz eines Index ein SQL auch funktioniert.

Wieder mal ein Problem des Optimizers, wobei es unabhängig davon ist, dass das Feld im Index erst an 2. Stelle kommt und der Index nicht hätte berücksichtigt werden dürfen.