ORA-01830 in Oracle beheben: TO_DATE richtig verwenden

Der Oracle-Fehler ORA-01830: Datumsformatstruktur endet vor Umwandlung der gesamten Eingabezeichenfolge tritt auf, wenn Oracle einen Text in ein Datum umwandeln soll, die verwendete Formatmaske aber nicht den gesamten Text abdeckt.

Ein typisches Beispiel ist ein Datumswert, der zusätzlich eine Uhrzeit enthält:

SELECT TO_DATE(
           '23.06.2026 14:30:00',
           'DD.MM.YYYY'
       )
FROM dual;

Die Formatmaske beschreibt nur:

23.06.2026

Die Eingabe enthält aber zusätzlich:

 14:30:00

Oracle kann den ersten Teil der Zeichenfolge verarbeiten. Danach bleiben jedoch Zeichen übrig, für die in der Formatmaske keine Entsprechung vorhanden ist. Das führt zu ORA-01830. Genau dies beschreibt auch die offizielle Oracle-Fehlerdokumentation: Ein Teil der Eingabe konnte als Datum interpretiert werden, aber nach dem Ende der Formatbeschreibung waren noch Daten vorhanden.

Die passende Lösung lautet:

SELECT TO_DATE(
           '23.06.2026 14:30:00',
           'DD.MM.YYYY HH24:MI:SS'
       )
FROM dual;

In der Praxis entsteht ORA-01830 allerdings nicht nur durch eine offensichtlich fehlende Uhrzeit. Besonders häufig wird der Fehler durch bereits konvertierte DATE-Werte, implizite Datentypumwandlungen, unterschiedliche NLS-Einstellungen oder nicht sichtbare Zeichen verursacht.

Die wichtigste Regel: TO_DATE verarbeitet Text und keine DATE-Werte

Die Funktion TO_DATE konvertiert eine Zeichenfolge vom Typ CHAR, VARCHAR2, NCHAR oder NVARCHAR2 in einen Oracle-Wert vom Datentyp DATE. Sie ist nicht dafür vorgesehen, einen bereits vorhandenen DATE-Wert erneut in ein Datum umzuwandeln.

Das korrekte Grundprinzip lautet:

VARCHAR2 → TO_DATE   → DATE
DATE           → TO_CHAR  → VARCHAR2

Daraus ergibt sich folgende Zuordnung:

Ausgangswert	Gewünschtes Ergebnis	Richtige Verarbeitung
`VARCHAR2`	`DATE`	`TO_DATE`
`DATE`	formatierter Text	`TO_CHAR`
`DATE`	`DATE`	keine Konvertierung
`DATE`	Datum ohne Uhrzeit	`TRUNC`
`VARCHAR2` mit Nachkommasekunden	`TIMESTAMP`	`TO_TIMESTAMP`
Fester Datumswert im SQL-Code	`DATE`	ANSI-Datumsliteral

Ursache 1: Die Eingabe enthält eine Uhrzeit

Fehlerhaft:

SELECT TO_DATE('23.06.2026 14:30:00', 'DD.MM.YYYY')
FROM dual;

Korrekt:

SELECT TO_DATE('23.06.2026 14:30:00','DD.MM.YYYY HH24:MI:SS')
FROM dual;

Bedeutung der verwendeten Formatelemente:

Element	Bedeutung
`DD`	Tag des Monats
`MM`	Monat als Zahl
`YYYY`	vierstelliges Jahr
`HH24`	Stunde im 24-Stunden-Format
`MI`	Minute
`SS`	Sekunde

Ein häufiger Fehler besteht darin, für Minuten versehentlich MM zu verwenden:

'DD.MM.YYYY HH24:MM:SS'

MM bedeutet bei Oracle Monat. Für Minuten muss MI verwendet werden.

Ursache 2: Die Eingabe enthält Nachkommasekunden

Folgender Wert ist kein reines Datum mit ganzen Sekunden:

23.06.2026 14:30:00.123456

Diese Eingabe enthält Nachkommasekunden. Dafür sollte TO_TIMESTAMP verwendet werden:

SELECT TO_TIMESTAMP('23.06.2026 14:30:00.123456','DD.MM.YYYY HH24:MI:SS.FF6')
FROM dual;

FF6 steht für sechs Stellen bei den Sekundenbruchteilen.

Für eine variable Anzahl von Nachkommastellen kann häufig FF ohne feste Stellenzahl verwendet werden:

SELECT TO_TIMESTAMP('23.06.2026 14:30:00.123','DD.MM.YYYY HH24:MI:SS.FF')
FROM dual;

TO_TIMESTAMP konvertiert Zeichenfolgen in den Datentyp TIMESTAMP. Oracle empfiehlt auch hier eine explizite Formatmaske, wenn das Eingabeformat bekannt und fest definiert ist.

Ursache 3: Die Eingabe enthält eine Zeitzone

Eine Zeichenfolge wie diese enthält zusätzlich einen UTC-Offset:

2026-06-23 14:30:00 +02:00

Sie sollte nicht mit einer einfachen TO_DATE-Formatmaske verarbeitet werden.

Geeignet ist beispielsweise:

SELECT TO_TIMESTAMP_TZ('2026-06-23 14:30:00 +02:00','YYYY-MM-DD HH24:MI:SS TZH:TZM')
FROM dual;

Die Elemente bedeuten:

TZH = Stundenanteil der Zeitzone
TZM = Minutenanteil der Zeitzone

Zeitzoneninformationen gehören zu den Timestamp-Datentypen. Die entsprechenden Formatbestandteile sind nicht für einen normalen Oracle-DATE-Wert vorgesehen.

Ursache 4: NLS_DATE_FORMAT unterscheidet sich zwischen den Systemen

SQL-Code kann in einer Entwicklungsumgebung funktionieren und in einer anderen Umgebung scheitern. Eine häufige Ursache sind unterschiedliche NLS-Einstellungen.

Die aktuelle Sitzung kann folgendermaßen geprüft werden:

SELECT parameter,value
FROM nls_session_parameters
WHERE parameter IN (    'NLS_DATE_FORMAT',    'NLS_TIMESTAMP_FORMAT',    'NLS_TIMESTAMP_TZ_FORMAT',    'NLS_DATE_LANGUAGE',    'NLS_TERRITORY')
ORDER BY parameter;

Mögliche Werte für NLS_DATE_FORMAT sind beispielsweise:

DD.MM.RR

DD-MON-RR

YYYY-MM-DD

DD.MM.YYYY HH24:MI:SS

Problematisch wird dies bei impliziten Konvertierungen:

SELECT *
FROM buchungen
WHERE buchungsdatum = '23.06.2026';

Die rechte Seite ist Text, die linke Seite ein DATE-Wert. Oracle muss daher einen Datentyp an den anderen anpassen. Das Ergebnis hängt möglicherweise vom Sitzungsformat ab.

Robuster ist:

SELECT *
FROM buchungen
WHERE buchungsdatum = TO_DATE('23.06.2026', 'DD.MM.YYYY');

Bei einem fest im SQL-Code stehenden Datum ist ein ANSI-Literal noch eindeutiger:

SELECT *
FROM buchungen
WHERE buchungsdatum = DATE '2026-06-23';

Oracle weist darauf hin, dass TO_DATE ohne Formatmaske nur zuverlässig funktioniert, wenn die Zeichenfolge genau dem durch NLS_TERRITORY beziehungsweise NLS_DATE_FORMAT festgelegten Standardformat entspricht. Bei einem bekannten Eingabeformat sollte deshalb eine explizite Formatmaske verwendet werden.

Ursache 5: Monatsnamen hängen von der Sprache ab

Numerische Datumswerte sind weitgehend sprachunabhängig:

23.06.2026

Bei ausgeschriebenen oder abgekürzten Monatsnamen spielt dagegen NLS_DATE_LANGUAGE eine Rolle.

Beispiel:

SELECT TO_DATE('23-JUNI-2026','DD-MONTH-YYYY','NLS_DATE_LANGUAGE=GERMAN')
FROM dual;

Für englische Monatsnamen kann die Sprache ausdrücklich festgelegt werden:

SELECT TO_DATE( '23-JUNE-2026','DD-MONTH-YYYY', 'NLS_DATE_LANGUAGE=AMERICAN')
FROM dual;

Die für Monats- und Tagesnamen verwendete Sprache wird durch NLS_DATE_LANGUAGE bestimmt. Dabei ist der Sitzungswert relevant, sofern im Funktionsaufruf keine Sprache ausdrücklich angegeben wurde.

Für technische Schnittstellen sind numerische Monate meistens robuster:

2026-06-23

DEFAULT NULL ON CONVERSION ERROR verwenden

Aktuelle Oracle-Versionen unterstützen bei TO_DATE einen Ersatzwert für fehlgeschlagene Konvertierungen:

SELECT TO_DATE(raw_date DEFAULT NULL ON CONVERSION ERROR, 'FXDD.MM.YYYY') AS konvertiertes_datum
FROM import_tabelle;

Ist raw_date nicht konvertierbar, liefert die Funktion NULL, statt wegen des Konvertierungsfehlers abzubrechen.

Alternativ kann ein festes Ersatzdatum angegeben werden:

SELECT TO_DATE(raw_date DEFAULT '01.01.1900' ON CONVERSION ERROR, 'FXDD.MM.YYYY')
FROM import_tabelle;

Ein künstliches Ersatzdatum wie 1. Januar 1900 sollte nur verwendet werden, wenn es fachlich eindeutig als Fehler- oder Standardwert definiert ist. Andernfalls kann es später wie ein echtes Geschäftsdatum behandelt werden.

Oracle weist außerdem darauf hin, dass die Ersatzzeichenfolge mit derselben Methode und derselben Formatmaske konvertiert wird. Ist auch der Ersatzwert ungültig, entsteht weiterhin ein Fehler.

DATE-Werte mit Uhrzeit richtig vergleichen

Ein Oracle-DATE enthält nicht nur Jahr, Monat und Tag, sondern auch Stunde, Minute und Sekunde. Ein Wert kann intern beispielsweise so aussehen:

2026-06-23 14:35:20

Diese Abfrage findet den Datensatz nicht:

SELECT *
FROM buchungen
WHERE buchungsdatum = DATE '2026-06-23';

DATE '2026-06-23' entspricht:

2026-06-23 00:00:00

Die Uhrzeiten stimmen daher nicht überein.

Eine fachlich saubere Tagesabfrage verwendet einen halboffenen Zeitraum:

SELECT *
FROM buchungen
WHERE buchungsdatum >= DATE '2026-06-23'  
AND buchungsdatum <  DATE '2026-06-24';

Für einen variablen Stichtag:

SELECT *
FROM buchungen
WHERE buchungsdatum >= TRUNC(v_stichtag)  
AND buchungsdatum <  TRUNC(v_stichtag) + 1;

Diese Variante erfasst sämtliche Uhrzeiten des Tages:

00:00:00 bis 23:59:59

Sie vermeidet außerdem problematische Konstruktionen wie:

TO_CHAR(buchungsdatum, 'DD.MM.YYYY') = '23.06.2026'

oder:

TRUNC(buchungsdatum) = DATE '2026-06-23'

Das Anwenden einer Funktion auf jede Tabellenzeile kann die Nutzung eines normalen Index auf der Datumsspalte erschweren. Oracle empfiehlt bei Datumsspalten mit Uhrzeit unter anderem Bereichsbedingungen, wenn sämtliche Werte eines Tages gefunden werden sollen

Zusammenfassung

ORA-01830 ist kein allgemeiner Fehler des Oracle-Datentyps DATE. Der Fehler zeigt an, dass eine Zeichenfolge und die verwendete Formatmaske nicht vollständig zusammenpassen.

Die wichtigsten Regeln sind:

TO_DATE ausschließlich für die Umwandlung von Text in DATE verwenden.
Bereits vorhandene DATE-Werte nicht erneut mit TO_DATE verarbeiten.
Für die Ausgabe eines Datums TO_CHAR verwenden.
Zum Entfernen der Uhrzeit TRUNC verwenden.
Uhrzeitbestandteile vollständig mit HH24:MI:SS abbilden.
Für Nachkommasekunden TO_TIMESTAMP und FF verwenden.
Implizite Datumsumwandlungen vermeiden.
Feste Datumswerte bevorzugt als DATE 'YYYY-MM-DD' schreiben.
Bei Importschnittstellen mit FX oder VALIDATE_CONVERSION validieren.
Bei PL/SQL-Fehlern die im ORA-06512-Stack genannten Package-Zeilen untersuchen.

Quellen und fachlicher Stand

Dieser Beitrag orientiert sich an der Oracle-Dokumentation zu ORA-01830, TO_DATE, TO_TIMESTAMP, Datumsformatmodellen, NLS-Einstellungen und ANSI-Datumsliteralen.