String in Datum umwandeln

Moderator: ModerationP

String in Datum umwandeln

Beitragvon Staatstheater » 18. Aug 2021, 08:33

Hallo zusammen,

ich habe eine Tabelle mit einem Feld vom Datentyp "kurzer Text".
in diesem Feld wird ein Datum in Stringform gespeichert. Das sieht so aus: 01.08.2018 - 17:00
Wie kann ich meine Daten umwandeln zu einem Feld vom Typ Datum/Uhrzeit tt.mm.jjjj - hh:nn
Benutzeravatar
Staatstheater
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 285
Registriert: 20. Dez 2011, 16:58
Wohnort: Saarland

Re: String in Datum umwandeln

Beitragvon KlausMz » 18. Aug 2021, 09:42

Hallo,
ersetze mit einer Aktualisierungsabfage das " - " durch ein einfachses Leerzeichen.
In der Aktualisierungszeile:
Code: Alles auswählen
Ersetzen([Datumsfeld];" - ";" ")

Dann kannst Du das Feld direkt in ein Datumsfeld ändern.
Gruß
Klaus . . . . . Feedback wäre wünschenswert.
Ich möchte bitte keine unaufgeforderten PN. Fragen bitte im Forum.
Benutzeravatar
KlausMz
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 40251
Registriert: 06. Okt 2003, 15:09
Wohnort: Irgendwo in der Pfalz

Re: String in Datum umwandeln

Beitragvon andyfau » 18. Aug 2021, 10:01

...oder als kleine Funktion in einem allgemeinen Modul, die man dann überall aufrufen kann, ohne die eigentliche Tabelle konvertieren zu müssen...

Code: Alles auswählen
Public Function Ausgabedat(Eingabedat As String) As Date
   Ausgabedat = Mid$(Eingabedat, 1, 11) + Mid$(Eingabedat, 14, 5)
End Function
Beste Grüße
Andreas
andyfau
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 41
Registriert: 17. Mär 2021, 21:45

Re: String in Datum umwandeln

Beitragvon Gast » 18. Aug 2021, 10:34

"zu einem Feld vom Typ Datum/Uhrzeit"

Wenn die Aussage keine Luftblase ist, benötigst Du eine Typumwandlung (CDate).
Ein entsprechendes Format kann man auch einem Date-Wert zuweisen, besser nur als Format-Eigenschaft.
Gast
 

Re: String in Datum umwandeln

Beitragvon Gast » 20. Aug 2021, 13:45

Hallo,
benötigst Du eine Typumwandlung (CDate)

Ich glaube, die macht hier keinen Sinn. Dann erscheinen auch die Sekunden, die der FS nicht haben will.
Dann käme auch ein Datumswert in ein Feld der Tabelle vom Typ Text. Das Tabellendesign passt also nicht.
Gruß Carla
Gast
 

Re: String in Datum umwandeln

Beitragvon Gast » 20. Aug 2021, 13:59

Den Unterschied zwischen Datentyp und Format sollte einem in einer Datenbank extrem vertraut sein - in Unterscheidung zu einer Exceltabelle, wo es keine Datentypen gibt, sondern nur Formate.

Zum Verständnis sollte man nur einmal den höchsten vorhandenen Datums-/Zeitwert ermitteln wollen. Bei Texten dürfte das Ergebnis unbefriedigend sein.
Gast
 

Re: String in Datum umwandeln

Beitragvon Gast » 20. Aug 2021, 15:18

Hallo,
Der Unterschied zwischen Datentyp und Format sollte einem in einer Datenbank extrem vertraut sein

Daher halte ich den Rat, die Werte mit CDate zu konvertieren, auch für falsch.
Durchaus kann man einen String wie 33.2.2021 mit Cdate umwandeln. Die Funktion liefert auch was, nur Falsches.
Also wie gesagt, das Tabellendesign ist falsch.
Gruß Carla
Gast
 

Re: String in Datum umwandeln

Beitragvon Bitsqueezer » 20. Aug 2021, 15:28

Hallo,

noch ein paar Anmerkungen dazu:

Eine Funktion wie "Ausgabedat" zu verwenden, ist extrem kurzsichtig. Da es sich um ein Textfeld handelt, kann nicht sichergestellt werden, daß das Format des Inhaltes immer genau dem entspricht, was zur Umwandlung notwendig ist.

Der richtige Weg ist natürlich die Umwandlung des Datentyps in der Tabelle in ein Datum/Zeitfeld und das enthält logischerweise auch einen Sekundenteil, der aber nicht stört, da die Originaldaten ja auch keine Sekunden enthalten, dieser wird also immer 0 sein. Für zukünftige Daten muß man dann eben den Sekundenteil selbst abschneiden (auf 0 setzen), bevor man einen Datensatz speichert und nicht einfach "Now()" verwenden.

Auch bei der Verwendung von CDate (generell den C-Funktionen) ist Vorsicht geboten: Diese richten sich leider nach den Windows-Regionaleinstellungen und können bei abweichender Einstellung falsche Ergebnisse liefern. Da im vorliegenden Fall das Ganze aber wohl eine einmalige Developer-Aktion ist, kann man den String auf beliebige Weise parsen und das Ergebnis vorab anschauen. Also die Klaus-Methode, die Andy-Methode oder die Gast-Methode. Wenn es dann für alle Datensätze paßt, kann man das umwandeln.

Ich würde hierbei (abhängig von der Zahl der Datensätze) erst ein neues DateTime-Feld erstellen, dann die Umwandlung in dieses Feld schreiben und am Ende vergleichen, ob die Werte übereinstimmen. Ist das der Fall, kann das Originalfeld gelöscht und das neue umbenannt werden (Index ggf. neu setzen, falls vorhanden).

Ein Format "tt.mm.jjjj - hh:nn" gibt es für das Feld natürlich nicht, da es auch nur einen Datums/Zeitdatentyp in Access gibt. Der ist immer "tt/mm/jjjj hh:nn:ss", also nicht in der Darstellung, sondern was die Werte angeht. Die Darstellung, also das Ausgabeformat "tt.mm.jjjj - hh:nn" wird ausschließlich im Formular/Bericht/Export (was auch immer) erstellt. Auch wenn Access (leider) die Formateinstellung bereits in der Tabellendefinition zuläßt, wo sie nicht hingehört. Das Format dort hat aber NICHTS mit der internen Speicherung zu tun, in dieser sind immer alle Teile eines Datums/einer Uhrzeit bis zu Sekunden enthalten.
Access läßt ein Format in der Tabellendefinition aus "geschichtlichen" Gründen zu, weil man bei den ersten Versionen den Fokus noch eher auf die Direktverarbeitung von Daten mit Hilfe eines Doppelklicks auf einen Tabellennamen gelegt hat. Daher gibt es in der Definition auch etwa die Nachschlagefelder, mit denen man z.B. einen ID-Wert gegen eine Kombobox mit Werten einer anderen Tabelle erstellen kann - damit bereits die Tabellenansicht aussieht und angewendet werden kann wie ein normales Endlosformular.

Gruß

Christian
Bitsqueezer
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 8462
Registriert: 21. Jun 2007, 12:17

Re: String in Datum umwandeln

Beitragvon Bitsqueezer » 20. Aug 2021, 15:31

Hallo Carla,

Durchaus kann man einen String wie 33.2.2021 mit Cdate umwandeln. Die Funktion liefert auch was, nur Falsches.


Wie kommst Du darauf? Das Ergebnis ist "Typen unverträglich". Der String ist in keiner Regionaleinstellung von Windows ein gültiges Datum. CDate nimmt sich die Windows-Regionaleinstellung für Datum und versucht, den String anhand der Einstellungen dort als Datum zu parsen, eine Umwandlung findet nur statt, wenn das möglich ist.

Gruß

Christian
Bitsqueezer
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 8462
Registriert: 21. Jun 2007, 12:17

Re: String in Datum umwandeln

Beitragvon Gast » 20. Aug 2021, 15:49

@Carla:
Bei allem würde ich noch einmal auf den Thementitel verweisen. Die Aussage darin ist doch wohl eindeutig.
Gast
 

Re: String in Datum umwandeln

Beitragvon Gast » 20. Aug 2021, 16:18

Hallo,
@Christian
Wie kommst Du darauf?

FS schreibt ja von einer Tabelle mit einem Feld vom Datentyp "kurzer Text", in dem er Zeitdaten hat.
In einer Textbox kann also sowas wie 32.3.21 17:00 stehen.
Schreibt man im Direktbereich z.B.
forms("frmBsp")!txtDatumText = cDate(forms("frmBsp")!txtDatumText)
so steht anschließend in der Box 21.03.2032 17:00:00. Also falsch.
Die Textbox merkt also nicht, dass was falsch ist und meckert auch nicht. Wäre sie gebunden an ein Datumsfeld, wäre schon der Fehler bei der Eingabe von Access bemerkt worden.
Daher mein Hinweis zum Tabellendesign.
@ Gast
auf den Thementitel verweisen. Die Aussage darin ist doch wohl eindeutig.

M.E. ist der Titel String in Datum umwandeln interpretierbar.
Da weiß man noch nicht, ob es ein Tipp ist oder ob es damit ein Problem gibt. Das erschließt sich also nicht durch die Überschrift, sondern durch den nachfolgenden Text.
Gruß Carla
Gast
 

Re: String in Datum umwandeln

Beitragvon Bitsqueezer » 20. Aug 2021, 16:42

Hallo Carla,

man kann doch nicht neu argumentieren, indem man den Wert verändert.

"32.3.21" kann ja auch als gültiges Datum interpretiert werden, "33.2.2021" dagegen definitiv nicht.

Den Umstand mit dem Formular brauchst Du nicht zu machen, einfach in VBA im Direktfenster probieren:

Code: Alles auswählen
?CDate("33.2.2021")


so steht anschließend in der Box 21.03.2032 17:00:00. Also falsch.


Nein, richtig. Denn nur das ist die sinnvolle Umwandlung dieses Wertes - auch auf keine andere Weise könnte man "32.3.21" in ein anderes Datum verwandeln. Also keine Ahnung, wo Du das Problem mit CDate siehst.

Der Punkt ist, daß ALLE Werte in dem Feld auf ein gültiges Datum geprüft werden müssen, bevor man sie umwandeln kann. "IsDate" ist eine Möglichkeit, aber genauso abhängig von den Systemdatumseinstellungen. Es gibt also nur die Möglichkeit, die Umwandlung automatisiert zu versuchen und das Ergebnis dann selbst zu überprüfen. Ein falsch geschriebenes Datum wie "32.3.21" ist als Datum interpretierbar, sollte aber nur umgewandelt werden, wenn es auch in anderen Feldwerten "JJ.MM.DD" ist. Und auch die Schreibweise ist zu berücksichtigen, also "32-3-21" oder "2032-03-21" oder "21.3.2032" usw.
Es muß also für eine schnelle Umwandlung erst mal die Datenkonsistenz geprüft werden, wenn alles die gleiche Schreibweise hat, kann man sich für die korrekte Umwandlungsmethode entscheiden. Wenn die Daten immer wieder anders vorliegen, muß man eine entsprechende Parserfunktion entwickeln oder die Daten manuell anpassen. Wie bei einem Textimport aus unbekannter Datenqualität etwa.
Und "CDate" ist dabei schon eine sehr gute Wahl, weil es sich schon große Mühe gibt, aus unterschiedlichsten Datenformaten ein korrektes Datum zu erraten.

Daher mein Hinweis zum Tabellendesign.

Du hast anscheinend die Aufgabe nicht verstanden. Es ging ja gerade darum, ein falsches Tabellendesign, nämlich ein Datum/Zeitfeld gespeichert als String, in ein echtes Datum/Zeitfeld umzuwandeln - also das Tabellendesign zu korrigieren.

Da weiß man noch nicht, ob es ein Tipp ist oder ob es damit ein Problem gibt. Das erschließt sich also nicht durch die Überschrift, sondern durch den nachfolgenden Text.

Wieviele Beiträge in einem Forum wie diesem kennst Du, die sich als Tip-Artikel darstellen...?

Dafür gab es mal im alten Forum ein Tip-Unterforum. Hier hat seither keiner mehr einen Tip-Artikel geschrieben. In 99,99999999999999% aller Erstbeiträge handelt es sich um eine Frage. Man gewinnt den Eindruck, daß Du jetzt unbedingt ein Argument verteidigen willst.
Darüber hinaus liest man ja den Text und nicht nur den Titel...

Gruß

Christian
Bitsqueezer
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 8462
Registriert: 21. Jun 2007, 12:17

Re: String in Datum umwandeln

Beitragvon Gast » 21. Aug 2021, 10:27

Hallo Christian,
Also keine Ahnung, wo Du das Problem mit CDate siehst.

?CDate("33.2.21") liefert 21.02.2033 OK
Aber stehen folgende Werte in einem String-Feld hätte man ein Problem. Wobei ein Vertipper in der letzten Zeile nicht unwahrscheinlich ist; statt 13.12.21 eben 13.22.21
Code: Alles auswählen
?CDate("33.22.21") ' 02.08.2809
?CDate("13.22.21") ' 02.01.2262

Mir fehlt da die Phantasie, das zu interpretieren und ziehe den Schluß, nicht zu gebrauchen.
Ich würde hierbei (abhängig von der Zahl der Datensätze) erst ein neues DateTime-Feld erstellen, dann die Umwandlung in dieses Feld schreiben

So sehe ich es auch und es entspricht ja auch der Frage vom Eingangspost.
Die Beiträge vom 18. Aug 2021, 10:01 und 18. Aug 2021, 10:34 belassen es beim Textfeld und damit beim Tabellendesign, was ich für falsch ansah, wobei die Klaus-Methode der direkten Typumwandlung des Textfelds in ein Datumsfeld nach der Replace- oder mid-Funktion (halte ich für besser wegen obiger CDate-Phänomene) auch zweckdienlich ist.
und am Ende vergleichen, ob die Werte übereinstimmen.

Wie stellt man denn den Vergleich am besten an?
Gruß Carla
Gast
 

Re: String in Datum umwandeln

Beitragvon Gast » 21. Aug 2021, 11:14

Sehr akademisch, diese Diskussion. Es gibt keinen Hinweis auf eine schlechte Datenqualität, und womöglich sind die Daten nur eine Formatierung von ursprünglichen (korrekten) DateTime-Werten.

Wie stellt man denn den Vergleich am besten an?

Anschauen und beurteilen, obwohl man da auch nicht sagen kann, ob ein 03.08. richtiger als ein 27.07. ist.

Texte kann man aber mit Textmethoden prüfen (vor einer Konvertierung). Da könnte man zumindest Werte mit Tageszahl größer 31 und Monatszahl größer 12 von Haus aus aussortieren, falls so etwas vorkommt.

Die ganze Diskussion mit Phantasiewerten könnte man sich zusätzlich sparen, wenn man Datumswerte als Datum erfasst, mit Datumspicker o.ä.
Dann kann man nur gültige Datumswerte bekommen. Ob die dann auch inhaltlich plausibel sind, wäre ein weiteres, aber anderes Thema.
Bei Texten kann man alles reinschreiben, auch Sternchen, Komma, Dollar, ... und was man kann, wird durchaus auch gerne genutzt.
Gast
 

Re: String in Datum umwandeln

Beitragvon Bitsqueezer » 22. Aug 2021, 00:31

Hallo Carla,

ich würde mal sagen, CDate hat entweder einen Bug oder das folgende müßte wohl stark interpretiert werden:

Microsoft hat geschrieben:CDate erkennt alle Datumsformate, die im Gebietsschema des Systems ausgewählt werden können. Die richtige Reihenfolge von Tag, Monat und Jahr kann nicht immer bestimmt werden, wenn sich das Datumsformat von den im Gebietsschema verfügbaren Formaten unterscheidet. Außerdem wird ein langes Datumsformat nicht erkannt, wenn es auch eine Zeichenfolge für den Wochentag enthält.


Code: Alles auswählen
?cdate("4.0.0")
03.02.1901
?cdate("4.0.00")
13.12.1910
?cdate("4.0.000")
06.07.2009
?cdate("4.0.0000")
27.02.2995
?cdate("4.1.0000")
04.01.2000


Kann man nicht mehr wirklich als "Interpretation eines Datums" bezeichnen...:)

Ich kann hier nur vermuten, daß CDate den String hier intern in einen Double-Wert umwandelt und dann versucht, ein Datum daraus zu machen..wäre aber nicht sehr logisch.

Aber vielleicht gibt es ja irgendeinen Kalender, der so eine Zahl als Datum akzeptiert, wenn ja ALLE möglichen Datumsvarianten geprüft werden...

Gruß

Christian
Bitsqueezer
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 8462
Registriert: 21. Jun 2007, 12:17

Nächste

Zurück zu Access Forum (provisorisch)

Wer ist online?

Mitglieder in diesem Forum: uwms und 9 Gäste