Und wieder mal SQL-Optimizer

[Fuerchau]

Die Datumskonvertierung wird ausschließlich in der Select-Liste durchgeführt.
In der Whereklausel erfolgt da kein Zugriff.
Wenn ich den SQL vereinfache und nur auf das Where ltlpdn > 20140000 prüfe, wird ein Index verwendet und die fehlerhaften Daten werden überlesen.
Sobald der volle SQL genommen wird, schmeißt der SQL einen Cast-Fehler auf das DATE... ins Joblog ohne Angabe einer Satznummer (Satznummer 0).

[dschroeder]

Ist deine Logik wirklich richtig? Warum werden denn an ltlpdn noch 6 Nullen drangekettet? Aus 6 Nullen wird doch nie ein vernünftiges Datum, oder?

[BenderD]

... es gibt halt keine Garantie auf eine bestimmte Reihenfolge der Auswertung von Klauseln zur Laufzeit (und das ist auch gut so!!!). Wenn man solche Huddeltadümmer hat, dann braucht man halt eine intelligentere Konvertierungsfunktion, die das rausmaskiert, oder man macht es richtig und saniert das im Datenbankdesign.

D*B

[dschroeder]

Hm, ich bin mir mit der Logik noch nicht sicher. Wenn ich das richtig verstehe, erzeugt digits doch einen String, der aus Ziffern besteht. Und mit "date" willst du das in ein echtes Datum umwandeln. Dann muss der String doch eine gültige Datumsrepräsentation ergeben (z.B. '2014-05-26' oder so).

Da ist der Zusammenbau doch etwas komplizierter, als einfach 6 Nullen dranzuhängen. Vielleicht mach ich aber auch gerade einen Denkfehler ...

[Fuerchau]

Nun, damit hast du bedingt recht. Es ist auch ein RPG-Timestamp (Anweisung Time) "JJJJMMTTHHMMSS" erlaubt.
Probiers aus...
Übrigens geht auch (ja nach PTF)
"DATE(CHAR(MyDate * 1000000))".
PTF ist deshalb wichtig, da SQL u.U. eine Integer-Multiplikation draus macht obwohl 14 Stellen nachweislich größer als 10 Stellen sind (davon nur 9 signifikante).

@D*B
haha...
Sag das mal den Kunden... mit ihrer Altanwendung.
Eine Whereklausel ist ein Filter auf die Daten, der früher (bis V6R1) immer vorab geprüft wurde.
Der Unterschied hier ist sogar noch so, dass eine UDF in der Select-Liste nicht aufgerufen wird, sondern erst auf den gefilterten Daten. Macht ja auch keinen Sinn, erst mal was zu berechnen was ich dann wieder wegschmeiße.

[BenderD]

@D*B
haha...
Sag das mal den Kunden... mit ihrer Altanwendung.
Eine Whereklausel ist ein Filter auf die Daten, der früher (bis V6R1) immer vorab geprüft wurde.
Der Unterschied hier ist sogar noch so, dass eine UDF in der Select-Liste nicht aufgerufen wird, sondern erst auf den gefilterten Daten. Macht ja auch keinen Sinn, erst mal was zu berechnen was ich dann wieder wegschmeiße.

... das mit den Altanwendungen, die Frage ist halt, ob man das im Viewlayer (DDS erstellt!!!) rausmaskieren kann, ich denke da an ein zusätzliches Feld, das man für die Altanwendung weglässt und per Trigger mitpflegt.
Was ich noch nicht ganz verstehe, wo knallt das wirklich? Das Feld LPLPDN finde ich im SQL Statement nicht.

Dieter

[BenderD]

Der Unterschied hier ist sogar noch so, dass eine UDF in der Select-Liste nicht aufgerufen wird, sondern erst auf den gefilterten Daten. Macht ja auch keinen Sinn, erst mal was zu berechnen was ich dann wieder wegschmeiße.

... dann reicht es doch bereits den date(digits(ltlpdn) concat '000000') in eine UDF zu wrappen, eleganter wäre natürlich die UDF mit Errorhandling zu versehen und im Fall invalider Daten null zurückzugeben.

D*B

[Fuerchau]

Entsprechende Routinen habe ich ja bereits bei anderen Kunden, ich denke, diese werde ich da mal hin migrieren müssen um diesem leidigen Problem vom Grundsatz aus dem Weg zu gehen.
Aber leider darf ich das aus unerfindlichen Gründen nicht bei jedem...(SOX lässt grüßen).