Unerwarteter SQL-Fehler in V6R1

[Fuerchau]

Nun will mein Kunde doch so langsam auf V6R1 umsteigen und prompt laufen schon bestimmte SQL's nicht mehr.

Ich habe eine TABLE mit einem Feld
CSKSENDUNG CHAR(10).

Über eine View wird das Feld umformatiert und in der Where-Klausel eingeschränkt:

SELECT
DEC(CSKSENDUNG, 7, 0) CSKSENDUNG
,DSENDEDAT
FROM RHTIA_16/SEKOPOOL
WHERE LENGTH(TRIM(CSKSENDUNG))=7
AND
TRIM(TRANSLATE(TRIM(CSKSENDUNG), 'X ', ' 1234567890'))=''

Bis V5R4 konnte ich dann das Feld CSKSENDUNG mit einem numerischen Wert suchen:

select * from RHTIA_16/TIAHDR
where CSKSENDUNG = 3

Bei V6R1 muss ich das nun mit einem korrekten Zeichenwert 7-stellig suchen:

select * from RHTIA_16/TIAHDR
where CSKSENDUNG = '0000003'

Der Fehler im Joblog ist:

Nachrichten-ID . . . . : CPD4019 Bewertung . . . . . . : 10 >>
Nachrichtenart . . . . : Diagnose >>
Sendedatum . . . . . . : 09.06.11 Sendezeit . . . . . . : 14:11:29 >>
>>
Nachricht . . . : SELECT/OMIT-Fehler in Feld Cast(SEKOPOOL_1.CSKSENDUNG AS >>
Decimal(7,0)), Teildatei TIAHDR. >>
Ursache . . . . : Ein SELECT/OMIT-Fehler ist in Satz 8539, Satzformat >>
*FIRST, Teildateinummer 1 der Datei TIAHDR in der Bibliothek RHTIA_16 wegen >>
Bedingung 6 der folgenden Bedingungen aufgetreten: >>
1 - Ein Dezimalfeld enthielt ungültige Daten. >>
2 - Ein SELECT/OMIT-Programmfehler ist aufgetreten (Daten in einem >>
SELECT/OMIT-Feld nicht mit SELECT/OMIT-Bestimmungen kompatibel). >>
3 - Ein SELECT/OMIT-Programmaufruffehler ist aufgetreten. >>
4 - Es wurde versucht, ein Gleitkommafeld, das keine Zahl war, zu >>
vergleichen. >>
5 - Ein DBCS-Feld enthielt ungültige Daten. >>
6 - Vor der SELECT/OMIT-Anforderung trat ein Datenzuordnungsfehler auf. >>
7 - Ein von einer Unterabfrage ausgewählter Satz enthält einen >>
Datenzuordnungsfehler. >>
8 - Das angegebene Escape-Zeichen war ungültig. >>
9 - Die Verwendung des Escape-Zeichens im angegebenen Muster war ungültig.>>
10 - Die Daten waren in einem Dezimalgleitkommafeld ungültig. >>
Trat der Fehler beim Versuch auf, einen bestehenden Satz abzurufen, >>
bezeichnet Teildatei TIAHDR, Datei TIAHDR, in der Bibliothek RHTIA_16 die >>
physische Datei, die das Feld enthält, das den Zuordnungsfehler verursacht >>
hat. Andernfalls trat der Fehler beim Versuch auf, eine Ausgabe- oder >>
Fortschreibungsoperation durchzuführen. Der Dateiname bezeichnet die offene >>
Datei, die das Feld enthält, das den Zuordnungsfehler verursacht hat. Ist >>
der Feldname *N, ist der Feldname entweder unbekannt oder ein Standardwert. >>


Mal sehen, wann IBM da mal ein PTF schickt da ich keine Lust habe alle Clientprogramme (ODBC-Zugriff) zu ändern.

[andreaspr@aon.at]

Ich habe dein Beispiel mal ausprobiert und bei V5R4 erhalte ich den gleichen SELECT/OMIT-Fehler wie bei V6R1:

Create table Tab1 (sp1 Char (10));
Insert Into tab1 values ('3');

Select * From Tab1 Where Sp1 = 3; --> Fehler
Select * From Tab1 Where Sp1 = '3'; --> OK

[B.Hauser]

... also

1. Die "Fehlermeldung" hat Level 10, d.h. ist also nur eine Warnung.
2. Hast Du Dir die Daten in Satz 8539 angeschaut? (am besten den Hex-Wert!)
3. Ich habe Deinen Source Code gerade abgetippt und auf einem V5R4 und 7.1 System ausprobiert (System mit 6.1 habe ich nicht im Zugriff), in beiden Fällen funktioniert eine Abfrage ohne Probleme.

Ich nehme an, dass es sich CSKSENDUNG in den Where-Bestimmungen um das konvertierte numerische Feld handelt. Sollte es sich um das alphanumerische Feld handeln, hast Du wahrscheinlich mit einem PTF schlechte Karten.

Ich tippe weiterhin auf unsaubere Daten.

Birgitta

[BenderD]

@Baldur:
was macht denn die View, wenn du sie komplett durchrattern lässt?
also create table new as(select * from myMonster)
oder notfalls ein count(*) oder max()???

wenn die an einem Satz stirbt, dann kann die Release Abhängigkeit an einer anderen Zugriffsstrategie hängen.

D*B

[Fuerchau]

@Birgitta
Die Daten sind sauber.
Wenn ich einfach einen SELECT * FROM VIEW mache erhalte ich keinen SQL-Fehler und die Daten werden korrekt angezeigt.
Die Umwandlung in numerisch läuft ohne Fehler.

Erst wenn ich die Where-Bedingung angebe bekomme ich den SQL-Fehler SQL0802 (die Warnung steht im Joblog davor).
Ich denke mal, dass der Optimizer die Where-Klausel der View "optimiert" also um meine Where-Bedingung ergänzt und somit sich der Fehler erklärt.

V5R4 fragt aber in diesem Fall wohl erst die Ergebnis-Tabelle ab, so dass dort die Abfrage läuft.

@Andreas
Deine Kurzform ist kein Ersatzbeispiel. Vergleichbar wäre das erst wenn du eine View mit Cast anlegst und deinen Select auf die View machst.

[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.