Datumsformat Kollision bei Mai

Moderator: ModerationP

Datumsformat Kollision bei Mai

Beitragvon benny66 » 02. Mai 2021, 16:34

Hallo,
ein Datumsfeld ist im Formular benutzerdefiniert so eingestellt, dass z.B. "2. Mai 2021" bei Eingabe von 2.5.21 gezeigt wird. Mai ohne Punkt; Kollision bei "Datum, mittel", da Mai mit Punkt "2. Mai. 2021"gezeigt wird.
Wird jetzt versehentlich 17:00 eingegeben, weil der User sich im Uhrzeit-Feld glaubt, so wird das akzeptiert. Es erscheint 30. Dez 1899. (Übrigens mal in einem offiziellen Schreiben einer Bank zu finden)
Also folgende Probleme: "Datum, mittel" liefert den Punkt hinter Mai. Die Korrektur durch das benutzerdefinierte Format tt. mmm jjjj führt zum fehlendem Punkt bei den langen Monaten.
Ich finde keine Lösung, die die bequeme Eingabe z.B. von "2.5.21" erlaubt, aber zugleich anschließend "2. Mai 2021" ohne Punkt! gezeigt wird.
Ist das möglich? Vielleicht weiß da ein Datumsexperte Rat. Oder muss das mit VBA geregelt werden?
Bei Eingabeformat wird übrigens tt. mmm jjjj nicht akzeptiert, unter Format kein Problem damit.
Gruß Benny
benny66
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 922
Registriert: 22. Nov 2015, 21:56

Re: Datumsformat Kollision bei Mai

Beitragvon KlausMz » 02. Mai 2021, 16:54

Hallo,
ich kann das nicht bestätigen. Mit der Eingabe von 2.5.21 wird mit dem Format tt.mmm jjjj der 02.Mai 2021 (ohne Punkt nach Mai) ausgeben. Bei jedem Monat.
Es muss das benutzerdefierte Format "t. mmm jjjj" verwendet werden, oder "tt. mmm jjjj" wenn man die führende 0 beim Monat haben will.

Ein Datum/Uhrzeitfeld speichert das Datum mit Zeit intern als Double ab. Vor dem Komma die Anzahl der Tage die seit dem 30. Dez 1899 vergangen sind. 1 enspricht also dem 31.12.1899.
Die Uhrzeit ist der dezimale Anteil eines Tages 17:00 = 0,70833333333333333333.
Vor dem Komma ist also eine 0. Wenn ein Datumsformat eingestellt ist, so entspricht das dem 30.12.1899 was auch richtig ist.

Bei Eingabeformat wird übrigens tt. mmm jjjj nicht akzeptiert, unter Format kein Problem damit.
Ein Eingabeformat ist auch was völlig anderes als das Format. Eine Formateinstellung kann man nicht im Eingabeformat eingeben, was auch logisch ist.
Schaue Dir die Hilfe zu den beiden Einstellungen an, dann wird Dir das klar.

Wenn Du sicherstellen willst dass ein passendes Datum eingetragen wird, so muss das über die Einstellungen (Gültigkeitsregel) oder über die Benutzeroberfläche geprüft und ggf. verhindert werden.
Ein Geburtsdatum z.B. könnte niemals in der Zukunft liegen. Oder ein Sterbedatum vor dem Geburtsdatum.
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: 40099
Registriert: 06. Okt 2003, 15:09
Wohnort: Irgendwo in der Pfalz

Re: Datumsformat Kollision bei Mai

Beitragvon knobbi38 » 02. Mai 2021, 18:46

Hallo Benny,

vielleicht helfen dir diese beiden Zuweisung, welche so nur in VBA gemacht werden können, z.B. im Form_Load():
Code: Alles auswählen
  txtDate.Format = "d/mmm yyyy"
  txtDate.InputMask = "99/99/9999;0;"" """


Gruß Ulrich
knobbi38
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 3261
Registriert: 02. Jul 2015, 14:23

Re: Datumsformat Kollision bei Mai

Beitragvon KlausMz » 02. Mai 2021, 22:18

Hallo,
Eingabeformate bei Datumsfeldern halte ich für eher hinderlich als nützlich.
Ist ein Eingabeformat definiert kann man kein Datum mehr ohne Jahr eingeben.
Ohne EF führt diese Eingabe 1.5 zu 01.05.2021. Oder 01. Mai 2021 mit Format. Der letzte Punkt und das Jahr müssen für das aktuelle Jahr nicht eingetragen werden, was recht praktisch ist. Mit EF führt das zu eine Fehlermeldung.
Außerdem lässt sich der Datumspicker nicht mehr benutzen, was auch ein ziemlicher Nachteil sein kann.
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: 40099
Registriert: 06. Okt 2003, 15:09
Wohnort: Irgendwo in der Pfalz

Re: Datumsformat Kollision bei Mai

Beitragvon knobbi38 » 02. Mai 2021, 23:26

Hallo,
Klaus hat geschrieben:Der letzte Punkt und das Jahr müssen für das aktuelle Jahr nicht eingetragen werden, was recht praktisch ist.

Im Gegenteil, wenn der zweite Punkt eingegeben wird, bekommt man eine Fehlermeldung, die nur mit einem Form_Error Handling behandelt werden kann. So einfach kann man es sich dann doch nicht machen.

Gruß Ulrich
knobbi38
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 3261
Registriert: 02. Jul 2015, 14:23

Re: Datumsformat Kollision bei Mai

Beitragvon KlausMz » 03. Mai 2021, 05:37

Hallo,
der 2. Punkt soll ja nicht eingegeben werden. Dann wird der Punkt und das aktuelle Jahr automatisch ergänzt. Da kommt keine Fehlermeldung.
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: 40099
Registriert: 06. Okt 2003, 15:09
Wohnort: Irgendwo in der Pfalz

Re: Datumsformat Kollision bei Mai

Beitragvon knobbi38 » 03. Mai 2021, 08:45

@Klaus:
Das ist das Problem mit den Anwendern, die machen immer das, was sie nicht sollen. :wink:

Grüße Ulrich
knobbi38
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 3261
Registriert: 02. Jul 2015, 14:23

Re: Datumsformat Kollision bei Mai

Beitragvon KlausMz » 03. Mai 2021, 08:48

Hallo,
die lernen das, sehr schnell, da bin ich ziemlich sicher. :badgrin:
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: 40099
Registriert: 06. Okt 2003, 15:09
Wohnort: Irgendwo in der Pfalz

Re: Datumsformat Kollision bei Mai

Beitragvon Gast » 03. Mai 2021, 16:39

Hallo,
@Klaus
ich kann das nicht bestätigen.

Hast du denn keinen Punkt bei Format "Datum, mittel"? Darauf bezog ich mich. Vielleicht hast du eine höhere Version als 2010 und MS hat das korrigiert?
Die Eingabe von 1.5 ist ja nur dann praktikabel, wenn es um das aktuelle Jahr geht. Und eine Lösung z.B. für die Eingabe der Kurzform 2.5.98, die dann als "2. Mai 1998" gezeigt wird, ist m.E. nicht durch eine Gültigkeitsregel erreichbar.
@Ulrich
Der Code hilft. Allerdings kommt bei der Fehleingabe z.B. der Uhrzeit die Meldung
"Der eingegebene Wert ist für die für dieses Feld angegebene Eingabemaske '99/99/999;0;" " unzulässig."

Da hat man bei MS mehr an den Entwickler gedacht als an den Endanwender, den das nur verwirrt.
Wie könnte man diese Meldung abfangen? Ich denke evtl. an Key-Events, die nur Zahlen und den Punkt erlaubt. Aber die Eingabe 1598 wäre dann ja erlaubt, führt aber auch zu einer Meldung, die verwirrt.
Also auch nicht so geeignet.
Gruß Benny
Gast
 

Re: Datumsformat Kollision bei Mai

Beitragvon KlausMz » 03. Mai 2021, 18:32

@Benny
Du machst ein Problem das keins ist. Die Eingabe von 1.5 war ja nur als Hinweis für Ulrich gedacht wegen des Eingabeformats. Und das mit der Gültigkeitsregel hat mit Deinem Problem nichts zu tun, das war auch nur ein Hinweis auf die Prüfung des eingegeben Datum auf Sinnhaftigkeit.
"Datum, mittel" sollst Du ja nicht verwenden. Das sind von MS vorbelegte Satndardformate die für Deinen Fall nicht geeignet sind. Das verwende ich auch nicht, es macht auch keinen Sinn das zu probieren, weil das hier nicht passt. Du musst das benutzerdefinierte Format "tt. mmm jjjj" (ohne die AZ) verwenden, dann klappt das wie gewünscht, ohne den Punkt nach dem Monat. Und verzichte einfach auf das Eingabeformat, dann kommt auch keine Meldung. Das ist hier in Deinem Fall kontraproduktiv und eher hinderlich. Dann kommt auch kein Fehler wegen der Uhrzeit. Allerdings kommt jetzt wieder ein Prüfung (Gültigkeitsregel) ins Spiel. Du musst prüfen, ob die Eingabe sinnvoll ist. Mit dem Format hat das nichts, absolut nichts zu tun.

Da hat man bei MS mehr an den Entwickler gedacht als an den Endanwender, den das nur verwirrt.
Da ist gar nix verwirrend. Sogar MS selbst empfiehlt Eingabeformate nur bedingt.
Zitat von MS:
Wann sollte die Verwendung von Eingabeformaten in Access vermieden werden
Obwohl Eingabeformate recht nützlich sind, sind sie nicht in jeder Situation geeignet. Verwenden Sie keine Eingabeformate, wenn die folgenden Bedingungen zutreffen:

Benutzer müssen gelegentlich Daten eingeben, die nicht dem Format entsprechen. Ein Eingabeformat lässt keine Ausnahmen zu.

Sie möchten ein Datumsauswahl-Steuerelement mit einem Feld für Datum/Uhrzeit verwenden. Eingabeformate sind nicht mit dem Datumsauswahl-Steuerelement kompatibel.
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: 40099
Registriert: 06. Okt 2003, 15:09
Wohnort: Irgendwo in der Pfalz

Re: Datumsformat Kollision bei Mai

Beitragvon knobbi38 » 04. Mai 2021, 11:57

Hallo Benny,

Fehlermeldungen in Zusammenhang mit Gültigkeitsregeln können nur im Form_Error Event abgefangen werden.
Wenn dir die standard Möglichkeiten nicht gefallen, beibt es dir unbenommen, eine eigene Wrapper-Klasse zu schreiben, die genau das gewünschte Verhalten zeigt und entsprechende Validierungen vornimmt und schon wird aus einer einfachen Textbox ein Steuerelement für die Datumseingabe. Gut, das findet man jetzt vielleicht nicht unbedingt auf Anhieb mit einer Suchmaschine, aber genau das ist die Aufgabe eines Programmierers.

Gruß Ulrich
knobbi38
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 3261
Registriert: 02. Jul 2015, 14:23

Re: Datumsformat Kollision bei Mai

Beitragvon Gast » 04. Mai 2021, 12:47

Hallo,
@Klaus
ich stelle das Problem der Klarheit wegen mal neu.
In einer Tabelle werden folgende Felder erstellt:
- StartDatum, Typ Datum/Uhrzeit
- StartUhrzeit, Typ Datum/Uhrzeit
Bei beiden keine weiteren Einstellungen zu Eigenschaften.
Die beiden Felder werden als txtStartDatum und txtStartUhrzeit in ein Formular eingefügt. Unter Eigenschaften:
txtStartDatum; unter Format tt. mmm jjjj
txtStartUhrzeit; unter Format hh:mm (wird umgewandelt von Access in Zeit, 24Std)
Ist der Anwender "brav", ist alles OK.
Jetzt eine Fehleingabe in txtStartDatum, da er sich im Feld Uhrzeit glaubt. Die Eingabe von 12:00 wird akzeptiert und anschließend 30.12.1899 gezeigt.
Oder eine andere Fehleingabe in txtStartUhrzeit, weil er sich im Feld Datum glaubt: Die Eingabe von 1.5.21 wird akzeptiert und anschließend 00:00 gezeigt.
Wie können solche Fehleingaben am einfachsten verhindert werden? Mit VBA, Gültigkeitsregel, Eingabeformat? Wobei bei Eingabeformat die Kurzeingabe t.m.jjj möglich sein soll.
@Ulrich
jetzt erst gelesen
Fehlermeldungen in Zusammenhang mit Gültigkeitsregeln können nur im Form_Error Event abgefangen werden.

Das liest sich so, dass man Code schreiben muss, um oben beschriebene Fehleingaben abfangen zu können. Dann braucht es wohl keine Gültigkeitsregeln. Unterschied bei den Eingaben ist ja das .-Zeichenin 1.5.21 bzw. das :-Zeichen in 12:00, die man durch das Key-Event prüfen kann. Geht das in die Richtung Wrapper-Klasse wie du schreibst? Oder meinst du ein Klassenmodul damit?
Gruß Benny
Gast
 

Re: Datumsformat Kollision bei Mai

Beitragvon Gast » 04. Mai 2021, 13:05

Wie können solche Fehleingaben am einfachsten verhindert werden?

Zuerst einmal über eine Bedienoberfläche, wo der User weiß, wo er ist und was er tut. Orientierungslosigkeit wäre ein Entwicklungsfehler.

eine Fehleingabe in txtStartDatum, da er sich im Feld Uhrzeit glaubt
...
Oder eine andere Fehleingabe in txtStartUhrzeit, weil er sich im Feld Datum glaubt

Man könnte nutzen, dass der Datentyp DateTime intern über eine Dezimalzahl (Double) ausgedrückt wird. Dabei sind die Ganzzahlen die Tage ab dem 30.12.1899, die Dezimalanteile sind Bruchteile eines Tages = Zeiten (Stunde = 1/24 usw.). Dem internen Wert sind die angezeigten Formate "wurscht".

Insofern wird ein Datum mit Ausnahme vom genannten 30.12.1899 >= 1 sein, eine pure Zeit < 1. Das könnte man sicher als Gültigkeitsregel einsetzen, bereits auf Tabellenebene. Eine zugehörige Meldung zur Gültigkeitsregel auf gleicher Ebene könnte bereits verständlich ein Problem beschreiben, so dass auf begleitendes VBA verzichtet werden kann.
Gast
 

Re: Datumsformat Kollision bei Mai

Beitragvon Gast » 04. Mai 2021, 13:19

Ich stelle fest, dass Klaus das oben ziemlich wörtlich schon mal geschrieben hatte.
Aufgabe: Lesen, verstehen, nicht gleich wieder vergessen, sondern anwendungsbereit in den eigenen Speicher (Hirn) legen.
Gast
 

Re: Datumsformat Kollision bei Mai

Beitragvon KlausMz » 04. Mai 2021, 13:26

Hallo,
das ist ja das, was ich die ganze Zeit sage.
Die Formateinstellung für die Felder (Datum und zeit) ist so OK, das kannst Du so lassen. Auf ein Eingabeformat bitte verzichten, sonst ist eine verkürzte Eingabe (t.mm.jj) nicht möglich.
Der Rest ist jetzt Datenvalidierung/Plausibilitätsprüfung. Mit Format oder Eingabeformat hat das jetzt nichts mehr zu tun. Die Datenvalidierung macht man entweder für alle Felder des Formular über das Formularereignis "Vor Aktualisierung" oder über da Feldereignis "Vor Aktualisierung".
Dabei werden die Eingaben auf Sinnhaftigkeit geprüft.
Wenn z.B. das Startdatum nicht vor dem aktuellen Datum liegen darf, kannst Du einfach so vergleichen:
Code: Alles auswählen
If Startdatum < Date Then
  MsgBox "Falsche Eingabe"
  Cancel = True
End if

Damit wäre auch gleich die Eingabe einer Uhrzeit abgefangen, denn die ist <1 und somit auch kleiner als das heutige Datum.
Du musst Dir jetzt Gedanken machen über sinnvolle Bedingungen für StartDatum und StartUhrzeit.
Für die Zeit, könntest z.B. auf einen bestimmten Bereich prüfen (z.B. zwischen 08:00 und 16:00).
Meine Bedingungen sind nur Beispiele, wie diese sinnvollen Prüfbedingungen für eine Validierung aussehen müssen kannst nur Du wissen.
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: 40099
Registriert: 06. Okt 2003, 15:09
Wohnort: Irgendwo in der Pfalz

Nächste

Zurück zu Access Forum (provisorisch)

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 5 Gäste

cron