SQL Date Between möchte einfach nicht gelingen

[Fuerchau]

Was soll man machen, wenn man auf Daten aus 20-jährigen ERP-Systemen auswerten will?
Ich habe ja gerade bei diesen ETL-Prozeduren aus verschiedensten Datenbanken genau diese verschiedenen Probleme.
Und da man sich halt auf den Optimizer nicht verlassen kann und der sowieso macht was er will muss man sich halt mit den Problemen herumschlagen.
Man kann auch nicht einfach so die Datenbasis ändern, denn immerhin läuft das ERP noch immer so und arbeitet eben nicht mit SQL. Und wenn es dann sog. allgemeine Tabellen gibt, die diverseste Daten aufnehmen so ist man halt bei ETL-Prozessen auf entsprechende SQL-Logik angewiesen.
Sicherlich muss man bei SQL lernfähig sein, denn was eben vor 10-15 Jahren galt führt eben heute zu Problemen.
Auf V5R1 habe ich eben schon mit SQL "rumgemacht" und es funktionierte eben ohne jedwede Veränderung bis V5R4. Erst der Wechsel dann auf V6R1 hat dank des Optimizers zum Absturz der SQL's geführt da der nun von nun an mal einen anderen Weg eingeschlagen hat.
Hätte ich mein Wissen von heute bereits vor 10 Jahren einsetzten können, wären diese Probleme eben nicht aufgetreten.
Da man kann gerne mit modernem Wissen daherkommen, wenn es dann vor 10 Jahren auch schon so gewesen wäre.
Und wer weiß, ggf. werden reine SQL-Prozeduren/Funktionen auch noch mal (wie Dieter schon sagte) optimiert.

[Fuerchau]

Nachtrag:
Und gerade was ETL angeht so ist es durchaus üblich, auf dem Quellsystem nichts ändern zu dürfen.
So schön das erstellen einer View oder UDF/UDT, einer Hilfstabelle auch wäre, es ist nicht erlaubt und wird auch nicht bezahlt. Ich kann dem Kunden nicht sagen, na dann, dann kann ich die Daten eben nicht auswerten.
Irgendeine Lösung gibt es immer.

@Birgitta
Ich habe mich ja nicht beschwert sondern nur darauf hingewiesen, dass man bei seinen Casts und Berechnungen eben genau das machen muss was du mir ja geradezu bestätigst.
Warum wiederholst du mich also nur und stellst es andersherum dar?
Und ich wollte eben nur darauf hinweisen, dass der Optimizer eben je nach Release und Lust und Laune anders entscheidet.
Bei einem ERP-System haben wir diverse UDF's generiert, die Standardfunktionalitäten der ERP-Software zur Verfügung stellten. Bis V6R1 war auch alles gut.
Seit V7R1 interressiert sich aber der Optimizer nicht mehr für Zwischensortierungen (also order By in CTE/Derived Tables). Diese kann man nun auch durchaus getrost vergessen.
Einzige Ausnahme sind scalare Subselects mit "Order by" und "Fetch first 1 rows only", diese funktionieren nach wir vor.
Ich war daher gezwungen, die UDF's mit eigenen Cachefunktionen zu ergänzen um immer noch performant arbeiten zu können.
Wie gesagt, je nach Release stoße ich halt immer mal wieder auf Neuerungen des Optimizers, die zu Verschlechterungungen bisheriger SQL's führen.
So extrem ist es leider erst seit V6R1, bis V5R4 waren die SQL's auch aus V4R3 noch kompatibel.

[BenderD]

Was soll man machen, wenn man auf Daten aus 20-jährigen ERP-Systemen auswerten will?
Ich habe ja gerade bei diesen ETL-Prozeduren aus verschiedensten Datenbanken genau diese verschiedenen Probleme.

Und gerade was ETL angeht so ist es durchaus üblich, auf dem Quellsystem nichts ändern zu dürfen.
So schön das erstellen einer View oder UDF/UDT, einer Hilfstabelle auch wäre, es ist nicht erlaubt und wird auch nicht bezahlt.

... für einen ETL Prozess reichen nach meiner Erfahrung singuläre SQL Statements nicht aus. Auch und gerade, weil die bei einem Problem an nicht vorhersehbarer Stelle einfach abbrechen. Wenn der ETL Prozess remote laufen soll und nur den Datenbank connect nutzen darf, dann muss die Komplexität auf die Maschine, auf der der Prozess läuft, verlagert werden - oder man hat die Probleme, die Du beklagst...

D*B