String in Datum umwandeln

Antwort erstellen

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :razz: :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: :badgrin: :doubt:
BBCode ist eingeschaltet
[img] ist eingeschaltet
[flash] ist ausgeschaltet
[url] ist eingeschaltet
Smilies sind eingeschaltet
Die letzten Beiträge des Themas
   

Ansicht erweitern Die letzten Beiträge des Themas: String in Datum umwandeln

Re: String in Datum umwandeln

Beitrag von Mr.TM » 23. Aug 2021, 17:16

Tut mir leid habe ich übersehen. :oops: War vom VBA abgelenkt, da ich es ja nicht benutzen darf. :doubt:

Re: String in Datum umwandeln

Beitrag von KlausMz » 23. Aug 2021, 14:10

Hallo,
... einfach von "kurzer Text" auf "Datum/Uhrzeit" umgestellt werden.

Das steht bereits in der 1. Antwort.

Re: String in Datum umwandeln

Beitrag von Mr.TM » 23. Aug 2021, 10:49

Hallo Staatstheater.

solange die Datumswerte der Form tt.mm.jjjj hh:nn:ss (mit Leerzeichen) entsprechen kann der Felddatantyp einfach von "kurzer Text" auf "Datum/Uhrzeit" umgestellt werden.

ACHTUNG: sollte die Form nicht entsprechend sein löscht Access den Feldwert!!!

Re: String in Datum umwandeln

Beitrag von Bitsqueezer » 22. Aug 2021, 13:34

Hallo,

ja, das meinte ich ja:

Ich kann hier nur vermuten, daß CDate den String hier intern in einen Double-Wert umwandelt und dann versucht, ein Datum daraus zu machen.


Das wäre aber schon ein komisches Vorgehen.

Gruß

Christian

Re: String in Datum umwandeln

Beitrag von EinAndererGast » 22. Aug 2021, 11:35

Bitsqueezer hat geschrieben:
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, ... "

?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

Wenn die zweite Zahl der drei Zahlen kein gültiger Tag oder Monat sondern 0 ist, dann werden von CDate anscheinend die Punkte ignoriert und alle Ziffern zu einer Zahl zusammengezogen, welche dann der Anzahl Tage seit 30.12.1899 entspricht:

Code: Alles auswählen
?cdate("400")
03.02.1901
?cdate("4000")
13.12.1910
?cdate("40000")
06.07.2009
?cdate("400000")
27.02.2995

:roll: :oops: :badgrin: :mrgreen: :P

Re: String in Datum umwandeln

Beitrag von 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

Re: String in Datum umwandeln

Beitrag von 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.

Re: String in Datum umwandeln

Beitrag von 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

Re: String in Datum umwandeln

Beitrag von 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

Re: String in Datum umwandeln

Beitrag von 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

Re: String in Datum umwandeln

Beitrag von 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.

Re: String in Datum umwandeln

Beitrag von 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

Re: String in Datum umwandeln

Beitrag von 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

Re: String in Datum umwandeln

Beitrag von 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

Re: String in Datum umwandeln

Beitrag von 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.

Nach oben

cron