SQL Date Between möchte einfach nicht gelingen

[B.Hauser]

Das Datum ist leider nicht das einzige Problem.
Früher klappte folgender SQL:

select dec(myFeld, 10, 0) from myfile where myFeld <> ''

myFeld enthält entweder Leerzeichen oder eine Zahl.
Heute kann es eben passieren, das "dec()" schon mal durchgeführt wird und der Where-Ausschluss erst danach kommt.
Da hilft auch nicht unbedingt ein "case when myFeld = '' then null else dec(myFeld, 10, 0) end", da ggf. alle Teilausdrücke schon mal ausgewertet werden.
Daher halt den Umkehrschluss:
"dec(case when MyFeld = '' then null else MyFeld end, 10, 0)"

Zu beachten ist, dass es egal sein muss in welcher Reihenfolge der Ausdruck berechnet wird um ohne Fehler weiter zu kommen.
Weiteres Beispiel:

case F2 when 0 then null else F1 / F2 end

Auch hier ist eben nicht garantiert, dass die Division nicht bereits vor dem Case ausgeführt wird.
coalesce(F1 / nullif(F2, 0), 0) garantiert aber das gewünschte Ergebnis, da nicht durch NULL dividiert wird.
Usw. usf.

Übrigens alles Erfahrungen aus meinem BI-Leben wo eben die fehlende Datenqualität nicht zum Absturz eines SQL's führen darf. Gerade bei ODBC liefert die AS/400 dann u.U. Teilergebnisse oder sogar falsche Ergebnisse, da im ODBC alle Felder einen NULL-Anzeiger haben, aber die Differenzierung zwischen tatsächlich NULL (-1) oder TRUNCATE (-2) auf Feldebene nicht mehr getroffen werden kann.
Der ODBC-Treiber wertet nämlich nur "-1" aus als NULL aus.

Zur Abwechslung muss ich mal Dieter recht geben:
Huddelduddel bleibt Huddelduddel.
Und diese Beispiele sind nicht richtig durchdacht und unlogisch und damit wie Dieter so schön sagt "Huddelduddel". Da braucht man sich nicht zu wundern, dass manches irgenwann mal anders läuft als man sich zurechtgezimmert hat.

1. Man versucht ein Feld das numerische Werte oder Blanks beinhaltet in numerische Werte umszusetzen. Vielleicht hätte man an dieser Stelle zunächst versuchen sollen die Daten dahingehend zu korrigieren, dass entweder das Blank durch eine Null oder einen echten NULL Wert ersetzt wird bevor man versucht zu konvertieren.
Das bedeutet nicht, dass man den Wert physische ändern muss, man kann diese Konvertierung auch innerhalb des Statements (aber an der richtigen Stelle durchführen).
Also: Dec(Case When Feld = '' Then '0' Else Feld End, 11, 0)
oder Dec(NULLIF(Feld, ''), 11, 0)

2. case when myFeld = '' then null else dec(myFeld, 10, 0) end genau das ist der falsche Ansatz. Zuerst muss myFeld so konvertiert werden, dass es einen numerischen Wert enthält, der dann konvertiert wird ... also:
Dec(NULLIF(MyFeld, ''), 11, 0)

Das gleiche gilt für Case F2 When 0 Then NULL else F1/F2 End. In diesem Beispiel wird zunächst dividiert und dann das Ergebnis konvertiert, was nur schiefgehen kann.
Zunächst muss F2 konvertiert werden und dannach erst darf die Division erfolgen, also:
F1/Case When F2 = 0 then NULL Else F2 End
oder
F1/NULLIF(F2, 0)

Eigentlich völlig logisch! Warum beschwert man sich, dass genau nach dieser Logik vorgegangen wird?

Das Problem ist nicht die fehlende Datenqualität, sondern der unsachgemäße und falsche Einsatz der skalaren Funktionen.
Nach meiner Erfahrung kann man alles (an der richtigen Stelle) prüfen und entsprechend konvertieren (ODBC oder nicht).
Mit den geeigneten Views, kann man die Konvertierungen wunderbar verstecken, so dass diese nur an einer einzigen Stelle erfolgen.

Ich hatte übrigens bei Konvertierungen von alpha nach numerisch nie Probleme (und hatte natürlich auch solche Fälle in denen Blanks in Spalten standen bzw. durch einen Wert dividiert werden musste).

Birgitta