SQL Programmierer

ORA-01861: literal does not match format string

Bei der Umwandlung von Strings in ein Datum mittels SQL kommt es manchmal zur Fehlermeldung:
ORA-01861: literal does not match format string
Diese ist ein häufiger Begleiter, wenn man das Datum als varchar2 oder sonstigen String gespeichert hat. Will man damit Berechnungen anstellen, muss es vorher mittels TO_DATE() in ein Datumsformat umgewandelt werden. Das funktioniert zwar meistens, aber hat man in den Daten varchar mit einem falsch formatierten Datumstring, dann kommt dieser Fehler bei Auswertung eines solchen Datums. Die Datenbank ist etwas flexibel und besteht nicht zu 100 Prozent auf Einhaltung des Formats, sondern glaubt auch fehlerhafte Angaben noch lesen zu können. Dadurch kann es aber zu falschen Umwandlungen kommen. Es ist besser die genaue Formateinhaltung bei der Auswertung zu erzwingen mittels FX im Formatstring. Solange irgendwo noch ein falsches Datum gespeichert ist, kommt der Fehler oder ein Folgefehler immer wieder mal vor, meistens zum ungünstigsten Zeitpunkt. Deshalb ist es besser, gleich gründlich damit aufzuräumen.

– Gewiss ist es sinnvoll, Datentypen zu verwenden, die als Datum deklariert sind und kein falsches Datum zulassen. Arbeitet man jedoch mit verschiedenen Datenbanken, je nachdem was der Kunde auf dem Server installiert hat, so kann es sinnvoll sein zwecks Portierbarkeit von Programm und Daten als Strings zu speichern. Denn Datumsspalten sind kaum datenbankübergreifend kompatibel, da sind sich die Datenbankhersteller wieder mal nicht einig. Ferner hat man oft Daten aus älteren Quellen oder aus CSV-, XML-Export usw. wo man selber keinen Einfluss hat auf den Datentyp und die Korrektheit.

– Daher bleibt oft nur das Ausfiltern ungültiger Datumsstrings, bevor das TO_DATE zum Einsatz kommt. Das TO_DATE macht man am besten am Ende einer CASE Struktur, darin können vorher alle ungültigen Fälle abgefangen und gesondert behandelt werden. Dann wird dort kein TO_DATE angewendet, weil das mit fehlerhaftem Datum nur eine Fehlermeldung oder ein fälschlich korrigiertes Datum ergibt. Da ist es besser selber zu korrigieren. Deshalb wird (unbedingt als erstes) geprüft, ob die Datumsangabe das Format erfüllt, normalerweise ‚YYYY-MM-DD‘ oder ein anderes angegebenes Format. Man muss dabei sicherstellen, dass dort wo Zahlen sein sollen wirklich nichts als Zahlen sind. Denn in der weiteren Datumsprüfung müssen Zahlen ausgewertet werden. Das erfordert eine Umwandlung des Strings in Zahlen und die würde einen anderen Fehler ergeben, wenn das nicht wirklich nur Zahlen sind. Nach der Formatprüfung können immer noch formal korrekte aber ungültige Datumsangaben vorkommen, die bei weiterer Verarbeitung zu weiteren Fehlern führen. Man muss also auch ungültige Datumsangaben vorher abfangen, wie z.B. 31.11.2013, 29.2.2001 oder im Standardformat 2013-11-31 und 2001-02-29. Dazu liest man mittels SUBSTR() die Jahreszahl, das Monat und den Tag. Damit stellt man verschiedene Bedingungen auf wann ein Datum gültig ist. Zum Beispiel darf der Monat nicht grösser als 12 sein. Dazu gehören auch die Regeln für den 29.Februar, den es nur in Schaltjahren gibt. Und Schaltjahr ist nicht alle 4 Jahre, sondern genau dann, wenn das Jahr durch 4 teilbar ist aber nicht durch 100 teilbar ist, oder wenn es durch 400 teilbar ist. So wird aus einer simplen Datumsumwandlung doch oft ein ganzer SQL-Block, wenn man fehlerhafte Datumsangaben nicht anderweitig ausschliessen kann. Nur so bekommt man eine immer funktionierende Abfrage, und nicht nur eine meistens funktionierende.