Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- elo:datums_werte_migrieren [2026/02/26 03:50] – 80.120.119.202
+++ elo:datums_werte_migrieren [2026/02/27 13:15] (aktuell) – [Nicht auf den objtstamp vergessen] 89.144.192.18
@@ Zeile 5: / Zeile 5: @@
 ===== Datenbankupdates? =====
-Kann ein günstiger Weg sein, muss es allerdings nicht. Das hängt dann doch ein wenig von der Datenbankengine ab und der Vielfalt, die hier hinter den Feldinhalten steht. Variieren die Datumsformate kann das eher ungünstig sein, hier wählt man ggf. am Besten den Weg eines neuen Feldes, um sicher zu gehen, dass man fehlerhafte Werte ggf. erkennen und anders adressieren kann. Fehlerhafte Werte einfach so zu beibehalten, kann zu Problemen bei anderen Komponenten führen. Bspw. bei der ESearch oder anderen Programmen, die bspw. mit ISO-Datumswerten arbeiten. Beim SQL-Server kann man hier gut und gerne mit TRY_CONVERT arbeiten, bei ORACLE mit REGEXP_LIKE oder ON CONVERSION ERROR. Bei Postgres stellt sich die Frage eher nicht, weil es diese Engine noch nicht so lange gibt, als das hier noch so alte Felder vorhanden sind.
+Kann ein günstiger Weg sein, muss es allerdings nicht. Das hängt dann doch ein wenig von der Datenbankengine ab und der Vielfalt, die hier hinter den Feldinhalten steht. Variieren die Datumsformate kann das eher ungünstig sein, hier wählt man ggf. am Besten den Weg eines neuen Feldes, um sicher zu gehen, dass man fehlerhafte Werte ggf. erkennen und anders adressieren kann. Fehlerhafte Werte einfach so zu beibehalten, kann zu Problemen bei anderen Komponenten führen. Bspw. bei der ESearch oder anderen Programmen, die bspw. mit ISO-Datumswerten arbeiten. Beim SQL-Server kann man hier gut und gerne mit TRY_CONVERT arbeiten, bei ORACLE mit REGEXP_LIKE oder ON CONVERSION ERROR. Bei Postgres stellt sich die Frage eher nicht, weil es diese Engine noch nicht so lange gibt, als das hier noch so alte Felder vorhanden sind. Im Fall des Falles kann man hier einfach ChatGPT oder ähnlich fragen.
+ISO-Datum in natives Datum:
+<file>
+SELECT CASE
+         WHEN REGEXP_LIKE(your_column, '^\d{8}$')
+         THEN TO_DATE(your_column, 'YYYYMMDD')
+         ELSE NULL
+       END AS converted_date
+FROM your_table;
+</file>
+Deutsches Datum in natives Datum:
+<file>
+SELECT CASE
+         WHEN REGEXP_LIKE(your_column, '^\d{2}\.\d{2}\.\d{4}$')
+         THEN TO_DATE(your_column, 'DD.MM.YYYY')
+         ELSE NULL
+       END AS converted_date
+FROM your_table;
+</file>
+Das native Datum kann man wieder wie folgt in ein ISO-Datum übersetzen:
+<file>
+SELECT TO_CHAR(SYSDATE, 'YYYYMMDD') AS formatted_date
+</file>
 ===== Nicht auf den objtstamp vergessen =====
-Wenn man sich hier wirklich an die Datenbank wagt, dann sollte man hier nicht vergessen den objtstamp zu aktualisieren. Ansonsten greift die ESearch das Objekt nicht mehr auf. Man kann alternativ aber auch eine komplette Neuindizierung starten, diese kann aber je nach Archivgröße auch dem entsprechend Zeit in Anspruch nehmen.
+Wenn man sich hier wirklich an die Datenbank wagt, dann sollte man hier nicht vergessen den objtstamp in der Tabelle Objekte zu aktualisieren. Er enthält einen Zeitstempel der UTC Zeitzone im Format yyyy.MM.dd.HH.mm.ss. Ansonsten greift die ESearch das Objekt nicht mehr auf. Man kann alternativ aber auch eine komplette Neuindizierung starten, diese kann aber je nach Archivgröße auch dem entsprechend Zeit in Anspruch nehmen. Aktualisiert man das Objekt über den IndexServer passiert hier alles automatisch über den Updater.