Probleme mit dem Datentyp Datum/Uhrzeit erweitert

Der Felddatentyp “Datum/Uhrzeit erweitert” wurde mit Access 2021 beziehungsweise mit Access aus Office 365 eingeführt. Er speichert genau wie der Datentyp “Datum/Uhrzeit” Datums- und Zeitangaben. Allerdings hat er eine höhere Genauigkeit und Uhrzeiten können nun auch Bruchteile von Sekunden enthalten. Der Grund für die Einführung ist die Herstellung von Kompatibilität mit dem SQL Server, der den Datentyp “datetime2” enthält. Wenn wir Tabellenverknüpfungen zu den Tabellen einer SQL Server-Datenbank herstellen, werden Felder des Typs “datetime2” automatisch mit dem neuen Access-Datentyp “Datum/Uhrzeit erweitert” übersetzt. Allerdings bringt das diverse Probleme mit sich. Zum Beispiel können die in Access eingebauten Datumsfunktionen nicht richtig mit diesem Datentyp umgehen. Was das im Detail bedeutet und welche Lösungsmöglichkeiten es gibt, erläutern wir in diesem Beitrag.

Grundlagenwissen: Interne Speicherung von Datumswerten

Bevor wir richtig einsteigen und für alle, die das noch nicht wissen: Datum-/Zeitwerte werden in Access intern als Double-Zahlen gespeichert.

Der Teil vor dem Komma entspricht der Anzahl der Tage seit dem 30.12.1899, der Teil nach dem Komma gibt den Anteil an einem kompletten Tag an – 0,5 entspricht also 12:00 Uhr, 0,75 entspricht 18:00 Uhr und so weiter.

Der Datentyp “Datum/Uhrzeit erweitert”

Für den Einstieg schauen wir uns den neuen Datentyp Datum/Uhrzeit erweitert einmal im Detail an und vergleichen diesen mit dem bisher verwendeten Datentyp Datum/Uhrzeit.

Beispieltabelle

Um mit dem Datentyp Datum/Uhrzeit erweitert zu experimentieren und die Unterschiede zum Datentyp Datum/Uhrzeit aufzuzeigen, wollen wir eine einfache Tabelle mit je einem Feld dieser beiden Datentypen anlegen. Dabei stoßen wir gleich auf den ersten Hinweis, dass die Verwendung unter Umständen kompliziert werden könnte …

Meldung beim Anlegen von “Datum/Uhrzeit erweitert”-Feldern

Wenn wir nämlich einer Datenbank erstmalig ein Feld mit dem Datentyp Datum/Uhrzeit erweitert hinzufügen und versuchen, die Tabelle zu speichern, erhalten wir die Meldung aus Bild 1.

Meldung beim Hinzufügen eines Datum/Uhrzeit erweitert-Feldes

Bild 1: Meldung beim Hinzufügen eines Datum/Uhrzeit erweitert-Feldes

Der Datentyp ist also nicht mit älteren Versionen von Access kompatibel, sprich: Mit Version 2019 und älter.

Wir haben die Probe gemacht und die Beispieldatenbank unter Access 2016 geöffnet. Gleich beim Starten erhalten wir die Meldung aus Bild 2. Daher an dieser Stelle der wichtige Hinweis: Wenn Sie Ihre Datenbankanwendung mit Benutzern teilen wollen, die Access 2019 oder älter verwenden, nutzen Sie nicht den Datentyp Datum/Uhrzeit erweitert. Das Gleiche gilt übrigens auch für den Datentyp Große Ganzzahl. In beiden Fällen kann die Datenbank nicht mehr mit älteren Access-Versionen geöffnet werden.

Versuch, eine Datenbank mit Datum/Uhrzeit erweitert-Feld in Access 2016 zu öffnen

Bild 2: Versuch, eine Datenbank mit Datum/Uhrzeit erweitert-Feld in Access 2016 zu öffnen

Vergleich zwischen “Datum/Uhrzeit” und “Datum/Uhrzeit erweitert”

In den folgenden Abschnitten schauen wir uns die offensichtlichen und auch die nicht so offensichtlichen Unterschiede zwischen den beiden Datentypen an.

Offensichtliche Unterschiede in einer Tabelle

Wenn wir je ein Feld der beiden Datentypen Datum/Uhrzeit und Datum/Uhrzeit erweitert anlegen und die Eigenschaften vergleichen, sehen wir einen zusätzlichen Eintrag bei dem neu eingeführten Datentyp. Diese Eigenschaft heißt Dezimalstellenanzeige (siehe Bild 3). Wozu benötigen wir bei einem Datum eine Dezimalstellenanzeige?

Zusätzliche Eigenschaft Dezimalstellenanzeige

Bild 3: Zusätzliche Eigenschaft Dezimalstellenanzeige

Ganz einfach: Eingangs haben wir schon erwähnt, dass dieser Datentyp nicht nur Datum und Uhrzeit speichern kann, sondern auch Bruchteile von Sekunden, also eine erweiterte Uhrzeit vergleichen zum Datum/Uhrzeit-Feld. Wie können also auch Werte wie den folgenden speichern:

12.04.2024 13:47:12.123456789

Die Eigenschaft Dezimalstellenanzeige gibt dabei schlicht an, wie viele Stellen der Bruchteile von Sekunden angezeigt werden sollen.

Wenn wir den Standardwert Automatisch übernehmen, erscheinen die Dezimalstellen bei Datum aus dem obigen Beispiel wie in Bild 4. Es wird also auf die siebte Nachkommastelle gerundet.

Standardanzeige der Dezimalstellen

Bild 4: Standardanzeige der Dezimalstellen

Wenn wir den Wert 0 für Dezimalstellenanzeige angeben, erscheinen Datum und Uhrzeit wie im herkömmlichen Datum/Uhrzeit-Feld.

Für die Werte von 1 bis 7 zeigt das Feld die jeweilige Anzahl an Nachkommastellen an.

Für Werte von 8 bis 15 (dem größten verfügbaren Wert) zeigt das Feld auch den auf die siebte Stelle gerundeten Wert an.

Kleinster Wert der Datums-Datentypen

Der kleinste Wert, den wir für Felder mit dem Felddatentyp Datum/Uhrzeit angeben können, ist der 1.1.100. Geben wir ein Datum wie 1.1.99 ein, interpretiert Access dies als 1.1.1999.

Geben wir für ein Datum/Uhrzeit erweitert-Feld den Wert 1.1.100 ein, wird dieses als 1.1.2024 interpretiert. Interessanterweise werden auch Eingaben wie 1.1.1984, 1.1.2023 oder 1.1.2030 in 1.1.2024 umgewandelt. Wir werden uns also gleich noch einmal genauer ansehen, wie man Datumsangaben richtig in Felder dieses Datentyps eingibt.

Vorher schauen wir uns noch an, welcher tatsächlich der kleinstmögliche Wert für ein Datum/Uhrzeit erweitert-Feld ist. Dieser lautet: 1.1.1.

Größter Wert der Datums-Datentypen

Der größtmögliche Wert für ein Feld mit den Datentyp Datum/Uhrzeit lautet 31.12.9999 23:59:59.

Der Datentyp Datum/Uhrzeit erweitert liefert fast den gleichen größtmöglichen Wert hängt jedoch noch ein paar Dezimalstellen dran, also lautet der angezeigte Wert 31.12.9999 23:59:59.9999999.

Das ist aber auch nur der Wert, den die Dokumentation von Microsoft liefert. Wir haben einmal den Wert 31.12.9999 23:59:59.9999999 eingegeben, der auch übernommen wird. Wenn wir jedoch noch eine 9 anhängen, also 31.12.9999 23:59:59.99999999, zeigt das Feld den Wert 31.12.9999 24:00:00.0000000 an. Was nach unserer Erwartung als 1.1.10000 00:00:00.0000000 angezeigt werden sollte.

In der Dokumentation wird als größter Wert für den Datentyp Datum/Uhrzeit übrigens 9999-12-31 23:59:59.999 angegeben – diesen Wert können wir weder in ein Feld dieses Datentyps eingeben noch lässt sich dieser mit VBA als Datum interpretieren (siehe Bild 5).

Fehler beim Auswerten von Dezimalstellen beim Datum

Bild 5: Fehler beim Auswerten von Dezimalstellen beim Datum

Merkwürdiges Eingabeverhalten bei “Datum/Uhrzeit erweitert”

Das Thema Eingabe haben wir weiter oben bereits angesprochen. Wir haben dort festgestellt, dass wir, wenn wir reine Datumsangaben außerhalb von 2024 eingeben, das Jahr immer auf 2024 geändert wird. Die Eingabe von 23.1.1971 wird in 23.01.2024 umgewandelt. Was genau läuft da schief? Wir haben uns den Inhalt einmal per VBA ausgeben lassen. Das wollten wir erst mit DLookup erledigen, was aber einen Fehler auslöste – dazu später mehr. Mit dem Zugriff über OpenRecordset hat es schließlich geklappt. Und hier ist das Ergebnis:

  CurrentDb.OpenRecordset("SELECT DatumUhrzeitErweitert FROM tblDatumsangaben").Fields(0)
01/23/2024 00:00:00.1971000

Access interpretiert die Jahreszahl im gelieferten Datum also offensichtlich als Dezimalteil der Sekunden. Tag und Monat werden korrekt verarbeitet, das Jahr jedoch nicht. Wenn wir ein Datum aus dem aktuellen Jahr eingeben, also beispielsweise 1.1.2024, wird die Jahreszahl auch nur scheinbar korrekt interpretiert – tatsächlich landet diese auch im Dezimalteil der Sekunden und das Jahr 2024 wird hinzugefügt. Hier der für die Angabe von 1.1.2024 gespeicherte Wert:

01/01/2024 00:00:00.2024000

Wie auch immer dies zu erklären ist: Die Eingabe von Datumsangaben in Felder des Typs Datum/Uhrzeit erweitert ist nicht in dem Format möglich, das in Deutschland üblicherweise verwendet wird. Aber wie müsste man das Datum korrekterweise eingeben?

Wenn wir das Datum wie in Bild 6 im Format dd.mm.yyyy hh:nn:ss eingeben, erhalten wir sogar eine Fehlermeldung. Hängen wir hier noch einen noch so kleinen Dezimalanteil an die Sekunden an, gelingt es – auch wenn dieser 0 lautet:

Fehler durch die Eingabe im regulären deutschen Datum/Uhrzeit-Format

Bild 6: Fehler durch die Eingabe im regulären deutschen Datum/Uhrzeit-Format

01.01.2024 12:00:00.0

Selbst wenn wir das Datum mit dem Datepicker auswählen, wird dieses nicht korrekt interpretiert. Die Auswahl des 1.1.2023 mündet wieder in diesem Wert:

Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...

den kompletten Artikel im PDF-Format mit Beispieldatenbank

diesen und alle anderen Artikel mit dem Jahresabo

Schreibe einen Kommentar