{"id":55001501,"date":"2024-06-01T00:00:00","date_gmt":"2024-06-02T21:20:34","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=1501"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"Probleme_mit_dem_Datentyp_DatumUhrzeit_erweitert","status":"publish","type":"post","link":"https:\/\/access-im-unternehmen.de\/Probleme_mit_dem_Datentyp_DatumUhrzeit_erweitert\/","title":{"rendered":"Probleme mit dem Datentyp Datum\/Uhrzeit erweitert"},"content":{"rendered":"

\"\"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.<\/b><\/p>\n

Grundlagenwissen: Interne Speicherung von Datumswerten<\/h2>\n

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

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.<\/p>\n

Der Datentyp „Datum\/Uhrzeit erweitert“<\/h2>\n

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

Beispieltabelle<\/h2>\n

Um mit dem Datentyp Datum\/Uhrzeit erweitert <\/b>zu experimentieren und die Unterschiede zum Datentyp Datum\/Uhrzeit <\/b>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 …<\/p>\n

Meldung beim Anlegen von „Datum\/Uhrzeit erweitert“-Feldern<\/h2>\n

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

\"Meldung<\/p>\n

Bild 1: Meldung beim Hinzufügen eines Datum\/Uhrzeit erweitert-Feldes<\/span><\/b><\/p>\n

Der Datentyp ist also nicht mit älteren Versionen von Access kompatibel, sprich: Mit Version 2019 und älter.<\/p>\n

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<\/b>. Das Gleiche gilt übrigens auch für den Datentyp Große Ganzzahl<\/b>. In beiden Fällen kann die Datenbank nicht mehr mit älteren Access-Versionen geöffnet werden.<\/p>\n

\"Versuch,<\/p>\n

Bild 2: Versuch, eine Datenbank mit Datum\/Uhrzeit erweitert-Feld in Access 2016 zu öffnen<\/span><\/b><\/p>\n

Vergleich zwischen „Datum\/Uhrzeit“ und „Datum\/Uhrzeit erweitert“<\/h2>\n

In den folgenden Abschnitten schauen wir uns die offensichtlichen und auch die nicht so offensichtlichen Unterschiede zwischen den beiden Datentypen an.<\/p>\n

Offensichtliche Unterschiede in einer Tabelle<\/h2>\n

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

\"Zusätzliche<\/p>\n

Bild 3: Zusätzliche Eigenschaft Dezimalstellenanzeige<\/span><\/b><\/p>\n

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<\/b>-Feld. Wie können also auch Werte wie den folgenden speichern:<\/p>\n

12.04.2024 13:47:12.123456789<\/pre>\n
Die Eigenschaft Dezimalstellenanzeige <\/b>gibt dabei schlicht an, wie viele Stellen der Bruchteile von Sekunden angezeigt werden sollen.<\/p>\n
Wenn wir den Standardwert Automatisch <\/b>übernehmen, erscheinen die Dezimalstellen bei Datum aus dem obigen Beispiel wie in Bild 4. Es wird also auf die siebte Nachkommastelle gerundet.<\/p>\n
\"Standardanzeige<\/p>\n
Bild 4: Standardanzeige der Dezimalstellen<\/span><\/b><\/p>\n
Wenn wir den Wert 0 <\/b>für Dezimalstellenanzeige <\/b>angeben, erscheinen Datum und Uhrzeit wie im herkömmlichen Datum\/Uhrzeit<\/b>-Feld.<\/p>\n
Für die Werte von 1 <\/b>bis 7 <\/b>zeigt das Feld die jeweilige Anzahl an Nachkommastellen an.<\/p>\n
Für Werte von 8 <\/b>bis 15 <\/b>(dem größten verfügbaren Wert) zeigt das Feld auch den auf die siebte Stelle gerundeten Wert an.<\/p>\n
Kleinster Wert der Datums-Datentypen<\/h2>\n
Der kleinste Wert, den wir für Felder mit dem Felddatentyp Datum\/Uhrzeit <\/b>angeben können, ist der 1.1.100<\/b>. Geben wir ein Datum wie 1.1.99 <\/b>ein, interpretiert Access dies als 1.1.1999<\/b>.<\/p>\n
Geben wir für ein Datum\/Uhrzeit erweitert<\/b>-Feld den Wert 1.1.100 <\/b>ein, wird dieses als 1.1.2024 <\/b>interpretiert. Interessanterweise werden auch Eingaben wie 1.1.1984<\/b>, 1.1.2023 <\/b>oder 1.1.2030 <\/b>in 1.1.2024<\/b> umgewandelt. Wir werden uns also gleich noch einmal genauer ansehen, wie man Datumsangaben richtig in Felder dieses Datentyps eingibt.<\/p>\n
Vorher schauen wir uns noch an, welcher tatsächlich der kleinstmögliche Wert für ein Datum\/Uhrzeit erweitert<\/b>-Feld ist. Dieser lautet: 1.1.1<\/b>.<\/p>\n
Größter Wert der Datums-Datentypen<\/h2>\n
Der größtmögliche Wert für ein Feld mit den Datentyp Datum\/Uhrzeit <\/b>lautet 31.12.9999 23:59:59<\/b>.<\/p>\n
Der Datentyp Datum\/Uhrzeit erweitert <\/b>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<\/b>.<\/p>\n
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 <\/b>eingegeben, der auch übernommen wird. Wenn wir jedoch noch eine 9 <\/b>anhängen, also 31.12.9999 23:59:59.99999999<\/b>, zeigt das Feld den Wert 31.12.9999 24:00:00.0000000 <\/b>an. Was nach unserer Erwartung als 1.1.10000 00:00:00.0000000 <\/b>angezeigt werden sollte.<\/p>\n
In der Dokumentation wird als größter Wert für den Datentyp Datum\/Uhrzeit <\/b>übrigens 9999-12-31 23:59:59.999 <\/b>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).<\/p>\n
\"Fehler<\/p>\n
Bild 5: Fehler beim Auswerten von Dezimalstellen beim Datum<\/span><\/b><\/p>\n
Merkwürdiges Eingabeverhalten bei „Datum\/Uhrzeit erweitert“<\/h2>\n
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 <\/b>wird in 23.01.2024 <\/b>umgewandelt. Was genau läuft da schief? Wir haben uns den Inhalt einmal per VBA ausgeben lassen. Das wollten wir erst mit DLookup <\/b>erledigen, was aber einen Fehler auslöste – dazu später mehr. Mit dem Zugriff über OpenRecordset <\/b>hat es schließlich geklappt. Und hier ist das Ergebnis:<\/p>\n
  CurrentDb.OpenRecordset(\"SELECT DatumUhrzeitErweitert FROM tblDatumsangaben\").Fields(0)\r\n01\/23\/2024 00:00:00.1971000<\/pre>\n
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:<\/p>\n
01\/01\/2024 00:00:00.2024000<\/pre>\n
Wie auch immer dies zu erklären ist: Die Eingabe von Datumsangaben in Felder des Typs Datum\/Uhrzeit erweitert <\/b>ist nicht in dem Format möglich, das in Deutschland üblicherweise verwendet wird. Aber wie müsste man das Datum korrekterweise eingeben?<\/p>\n
Wenn wir das Datum wie in Bild 6 im Format dd.mm.yyyy hh:nn:ss <\/b>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 <\/b>lautet:<\/p>\n
\"Fehler<\/p>\n
Bild 6: Fehler durch die Eingabe im regulären deutschen Datum\/Uhrzeit-Format<\/span><\/b><\/p>\n
01.01.2024 12:00:00.0<\/pre>\n
Selbst wenn wir das Datum mit dem Datepicker auswählen, wird dieses nicht korrekt interpretiert. Die Auswahl des 1.1.2023 <\/b>mündet wieder in diesem Wert:<\/p>\n
01\/01\/2024 00:00:00.2023000<\/pre>\n
Datum\/Uhrzeit-Datentypen unter VBA<\/h2>\n
Wie man mit Werten aus Feldern mit dem Datentyp Datum\/Uhrzeit <\/b>umgeht, brauchen wir hier nicht mehr zu erläutert – Funktionen wie DLookup<\/b>, CDate<\/b>, Year<\/b>, Month<\/b>, Day<\/b>, DateAdd <\/b>et cetera sind sicherlich bekannt.<\/p>\n
Wie aber arbeiten diese Funktionen mit dem Datentyp Datum\/Uhrzeit erweitert <\/b>zusammen? Das schauen wir uns nun an.<\/p>\n
Feldwert ermitteln<\/h2>\n
Als Erstes wollen wir einfach den Wert eines Datum\/Uhrzeit erweitert<\/b>-Feldes ermitteln. Üblicherweise ist die DLookup<\/b>-Funktion innerhalb von Access ein probates Mittel für diesen Zweck. Wie Bild 7 zeigt, funktioniert diese Funktion jedoch nicht mit dem Datum\/Uhrzeit erweitert<\/b>-Feld.<\/p>\n
\"Fehler<\/p>\n
Bild 7: Fehler bei Verwendung von DLookup<\/span><\/b><\/p>\n
Wie können wir nun per VBA auf die Daten dieses Feldes zugreifen? Dazu verwenden wir, wie bereits weiter oben demonstriert, die OpenRecordset<\/b>-Methode und geben den Inhalt des gesuchten Feldes wie in Bild 8 aus.<\/p>\n
\"Ermittlung<\/p>\n
Bild 8: Ermittlung des Wertes eines Feldes mit dem Datentyp Datum\/Uhrzeit erweitert<\/span><\/b><\/p>\n
Wie können wir damit als Datum weiterarbeiten? Üblicherweise hätten wir dazu die CDate<\/b>-Funktion verwendet. Der folgende Befehl liefert allerdings ebenfalls den Fehler 13 <\/b>(Typen unverträglich<\/b>):<\/p>\n
  CDate(\"01\/01\/2024 00:00:00.2024000\")<\/pre>\n
Wenn wir in einer Abfrage die ZDatum<\/b>-Funktion auf ein Datum\/Uhrzeit erweitert<\/b>-Feld anwenden, erhalten wir als Ergebnis #Fehler<\/b>.<\/p>\n
Die Datumsfunktionen Jahr<\/b>, Monat<\/b>, Wochentag<\/b>, Tag<\/b>, Stunde<\/b>, Minute<\/b>, Sekunde<\/b>, DatAdd<\/b>, DatDiff <\/b>und DatTeil <\/b>funktionieren jedoch, genauso wie die VBA-Pendants Year<\/b>, Month<\/b>, Weekday<\/b>, Day<\/b>, Hour<\/b>, Minute<\/b>, Second<\/b>, DateAdd<\/b>, DateDiff <\/b>und DatePart<\/b>.<\/p>\n
Dies sind allesamt Funktionen, die Informationen aus einem Datum herausziehen, was auch beim erweiterten Datumstyp gelingt. Was aber ist mit den Funktionen, mit denen wir Datum- und Zeitinformationen erzeugen?<\/p>\n
Diese sind vorhanden, wenn auch nicht dokumentiert und nur in Abfragen. Die Funktionen heißen wie folgt und werden im Gegensatz zu den übrigen eingebauten Access-Funktionen nicht in die deutsche Version übersetzt, wenn man sie auf Englisch eingibt:<\/p>\n