Fehlerhinweis verhindern

[Herby49]

Hallo
Ich verwende Accesss2010 und habe ein paar grundlegende Fragen:

In einem Programm verwende ich zwei ungebundene Steuerfelder, in das der Anwender ein Datum eingeben muss. Beide Datumswerte werden später in einem SQL-String zum Filtern der Datensätze verwendet.

Ich habe bei den Eigenschaften der Textfelder bei "Format" ausgewählt: "Datum kurz", damit  das Textfeld einen Datepicker bekommt.
Die Eigenschaft "Eingabeformat" habe ich leer gelassen, weil bei einem Datum-Eingabeformat der Datepicker (leider automatisch) wieder entfernt wird.
Ich möchte aber einerseits dem Anwender die Chance geben, den DatePicker zu benutzen, um z.B. bei der Datusauswahl sehen zu können, um welchen Wochentag es sich handelt.

Andere User werden aber wahrscheinlich das Datum eintippen, weils schneller geht.  Dabei wird dann auch sicher schon mal in der Eile ein Datum wie z.B. der 1. Jan. 2012 als 1112, oder 010112 oder wie auch immer eingegeben.
An der Stelle möchte ich dem Anwender Arbeit abnehmen und im Hintergrund versuchen, das Datum mit VBA-Code in eine gültige Form (01.01.2012) bringen, konkret also: Fehlende Trennzeichen einfügen und falsche Datums-Trennzeichen (",") durch "." austauschen. Das wäre ist auch kein Problem, wenn mir nicht die Access-Fehlermeldung: "Sie haben einen Wert eingegeben, der für dieses Feld nicht zulässig ist!".

Ich habe m.E. jetzt schon bei allen zum Steuerfeld zugehörigen Ereignissen versucht, per Code die Korrektur durchzuführen - vergebens, denn die Fehlermeldung kommt mir immer zuvor. Auch wenn ich die Warnmeldungen ausschalte (was man ja eigentlich nicht tun sollte) erscheint der Fehlerhinweis unverändert.

Konkrete Frage:
1. Gibt es ein Ereignis, bei dem ich die Eingabe des Feldes per Code korrigieren kann, so dass die o.a. Meldung unterbleibt?
2. Kann ich die Access-Meldung ersetzen durch eine eigene Meldung - wenn ja: bei wlcher Ereignis-Eigenschaft

1000 Dank für "sachdienliche Hinweise".

Herby

[bahasu]

N'abend,

vielleicht ist ein anderes Kalendersteuerelement zusammen mit a2010 besser in Gegenwart einer Eingabeformatanweisung geeignet.
z.B. MSCAL.Kalender-Steuerelement.7
Unter a2003 ist damit sowohl ein Kalender als auch das Eingabeformat (99.99.9999;0;_) nutzbar.

Harald

[Beaker s.a.]

Hallo Herby,

Dabei wird dann auch sicher schon mal in der Eile ein Datum wie z.B. der 1. Jan. 2012 als 1112, oder 010112 oder wie auch immer eingegeben.

Kannst Du das Feld nicht mit einen Standardwert (Date) vorbelegen?

wenn mir nicht die Access-Fehlermeldung: "Sie haben einen Wert eingegeben, der für dieses Feld nicht zulässig ist!".

Da liegt wohl ein Konflikt auf Tabellenebene vor; - schau Dir die Feldeigenschaften in der Tabelle noch mal an.
Oder zeige mal den Code, mit dem Du die Eingabe in ein Datum umwandelst.

1. Gibt es ein Ereignis, bei dem ich die Eingabe des Feldes per Code korrigieren kann, so dass die o.a. Meldung unterbleibt?
2. Kann ich die Access-Meldung ersetzen durch eine eigene Meldung - wenn ja: bei wlcher Ereignis-Eigenschaft

Für Validitätsprüfungen sollte Feld_BeforeUpdate das geeignete Ereignis sein. Der Fehler ist davon aber unabhängig.
Im gleichen Ereignis kannst Du im ErrorHandling den Fehler mit der nur Dir bekannten Fehlernummer abfangen, und eine eigene Meldung ausgeben.

hth
gruss ekkehard

[Herby49]

Hallo Ekkehard
zunächst einmal herzlichen Dank für die nun wirklich schnelle Reaktion.

Zu Deiner Antwort:

Kannst Du das Feld nicht mit einen Standardwert (Date) vorbelegen?

Es handelt sich - wie schon gepostet - nicht um ein Tabellenfeld, sondern um ein ungebundenes Textfeld. Dieses Feld dient dazu, z.B. den Beginn einer Beschäftigung aufzunehmen (es gibt dann ein weiteres Textfeld für das Ende eines Beschäftigungsferhältnisses, beide Felder zusammen geben die herauszufilternden Daten aus einer DB an.

Da liegt wohl ein Konflikt auf Tabellenebene vor; - schau Dir die Feldeigenschaften in der Tabelle noch mal an.
Oder zeige mal den Code, mit dem Du die Eingabe in ein Datum umwandelst.

Siehe oben: Es geht nicht um Tabellenfelder. Und dass ein Konflikt vorliegt ist klar: Ich habe ja unter der Eigenschaft "Format" "Datum" eingegeben, muss aber damit rechnen, dass der Anwender sich nicht daran hält. Anstatt ihm die Fehlermeldung um die Ohren zu schlagen, will ich erst mal versuchen, ob ich per Code aus der Eingabe ein Datum machen kann, indem ich - wie geschildert - zum Beispiel die richtigen Datumstrennzeichen an der richtigen Stelle setze usw.

Für Validitätsprüfungen sollte Feld_BeforeUpdate das geeignete Ereignis sein. Der Fehler ist davon aber unabhängig.
Im gleichen Ereignis kannst Du im ErrorHandling den Fehler mit der nur Dir bekannten Fehlernummer abfangen, und eine eigene Meldung ausgeben.

Das werde ich heute Nachmittag (noch) mal versuchen - ich hatte zwar angenommen dieses Ereignis schon für eine Validitätsprüfung gecheckt zu haben - aber vielleicht hatte ich die falsche Fehlernummer...

Erst einmal vielen Dank
Herby

[Herby49]

Hallo Harald
Danke für den Tipp. Ich hatte auch schon ein vorhandenes AktiveX-Kalenderelent auf meinem Rechner gefunden (Microssoft), aber zum einen erscheint mir dieses zu "groß / protzig", zum anderen muss ich es dann ja auch an die Kunden weitergeben (Copyright??). Da wäre mir - ehrlich gesagt - eine andere Lösung (eben die Validierung per VBA-Code) lieber.
Trotzdem Danke!

Gruß
Herby

[MzKlMu]

Hallo,
um welchen Wertebereich (Datum von/bis) geht es denn?
Immer um das aktuelle Datum herum?
Wie weit zurück?
Wie weit vor?

[Herby49]

Hallo
es sind alle gültigen Daten von01.01.1940 bis aktuell heute denkbar - oder eben auch leere Felder, wenn es keine Selektion / Filterung geben soll.
Aber das ist m.E. für den Kern des Problems doch egal - oder?

Gruß
Herby

[DF6GL]

Hallo,

Dabei wird dann auch sicher schon mal in der Eile ein Datum wie z.B. der 1. Jan. 2012 als 1112, oder 010112 oder wie auch immer eingegeben.

Naja, da würde ich den Anwendern mal auf die Finger klopfen....

oder wie auch immer eingegeben

ist sowieso nicht vollständig abdeckbar...


Wenn ein falscher Datumswert  mit einem gültigem Datumsformat eingegeben wird,  dann bekommt man das nicht zu fassen....

[Herby49]

Na ja, wenn einer "Müll" in ein Datumsfeld schreibt, der hat dann auch verdient, dass ihm per Access-Fehlermeldung geholfen wird. Aber ansonsten schreibe ich gerne Programme, die anwenderfreundlich sind. will in diesem Fall heißen: aus "010112" würde ich zum Beispiel dann gerne "01.01.2012" machen. Ich halt's halt besser als eine "erzieherische Maßnahme" in Form einer Access-Belehrung 

[DF6GL]

Hallo,


na gut, dann könntest Du in der EXIT-Ereignisprozedur des Datumsfeldes eine Überprüfung/Korrektur des eingegebenen Textes durchführen und das Ergebnis dem Textfeld wieder zuweisen.

[Herby49]

Hallo Franz
Klappt nicht: Kein Ereignis des TextFeldes nach einer Datumseingabe verhindert eine Fehlermeldung bzw lässt zu, dass der Fehler per VBA-Code abgefangen wird. Da ist Access einfach "schneller" und bringt seine Meldung an den Mann / die Frau.
Ich verzweifle langsam.
Eine Fehlerbehandling ist bei diesem Fehler nur über das Form-Ereignis "Bei Fehler" möglich (z.B. Ausgabe einer eigenen Fehlermeldung) Eine anschließende Wertzuweisung an das Feld ist da aber auch nicht möglich, bzw. führt unweigerlich zu einem Laufzeitfehler.

Verstehen tu ich's nicht: Access bietet so viele Möglichkeiten, aber hier scheint's in der Tat nichts zu geben?!?

[ebs17]

Eine Textbox in einem Formular ist vom Typ Variant. Bindet man ein Feld einer Tabelle/Abfrage an dieses Feld oder vergibt man ein Format für das ungebundene Textfeld, übernimmt die Textbox den daraus ableitbaren Datentyp.
Wenn das Feld also mit "Datum, kurz" formatiert ist, akzeptiert es nur gültige DateTime-Werte im gleichen Format sowie in einigen ähnlichen Formaten (24.1 würde als 24.01.2011 interpretiert / Jahreszahl aus aktuellem Jahr). Freie Zahlen- und/oder Texteingaben werden nicht akzeptiert, das ist auch nicht über Ereignisprozeduren abbiegbar.

Wenn Du also dem Bediener freie kreative Eingaben gönnen willst, verwende ein ungebundenes unformatiertes Feld und versuche nachfolgend, diese Eingabe als gültiges Datum zu interpretieren (wobei der Fall nicht einfach ist, ein gültiges Datum als gewünschtes Datum zu validieren) und als gültigen Wert an die Abfrage weiterzugeben.

MfGA
ebs

[MzKlMu]

Hallo,

Aber das ist m.E. für den Kern des Problems doch egal - oder?

ich hatte schon meine Hintergedanken, bei der Frage. Bin aber erste jetzt wieder an den Rechner gekommen.
Ich würde eine Tabelle anlegen mit allen Datumswerten von 1940 bis meintwegen 2020. Wenn notwendig, gleich ohne Wochenenden.
Diese Tabelle dann in einem Kombi zur Auswahl darstellen. Wennn man in das Kombi etwas eintraägt, wird der Eintrag immer mehr verfeinert, bis zum gewünschten Datum. Es sind nicht mehr Tastendrücke wie mit dem Textfeld notwendig und ein falsches Datum ist völlig ausgeschlossen. Damit entfällt jedigliche Prüfung auf gültiges Datum, es geht kein anderes. Du brauchst auch keine Fehlermeldung mehr. Und einfach ist es auch. Die Datumstabelle kannst Du einfach mit Excel erzeugen und importieren.
Auch vor dem Hintergrund, dass eine Datumsvalidierung nicht ganz einfach ist. Die Prüfung IsDate lässt auch das US Format durchgehen. 12.31.2011 wird als gültig aktzepiert. Mit dem Kombi hast Du das Problem erschlagen.

[Herby49]

Hallo ebs17
hallo MzKIMu

Nachdem es also offensichtlich nicht möglich ist, eine einmal erfolgte Eingabe in einem Feld mir definiertem Format (Datum) vor der "Übergabe" an Access noch einmal zu verändern, denke ich, dass (auch unter ergonomischen Gesichtspunkten) der Vorschlag von ebs17 der "Vernünftigste" ist.
Vielleicht sollte ich Herrn Microsoft anrufen und ihn bitten, sein formatiertes Textfeld zu verbessern (dass so etwas geht, sehe ich jeden Tag bei meiner Buchhaltung mit Lexware: Dort gibts den Datepicker und trotzdem kann ich 6 Ziffern in das Feld tippen, die in ein richtiges Datumsformat umgewandelt werden - vorausgesetzt es ergibt sich durch die Umwandlung ein sinnvolles Datum).

Allen Antwortern ein herzliches Dankeschön. War zum ersten Mal im Forum und hätte nicht gedacht, so schnelle Hilfstellung zu bekommen!!!

Herby

[MzKlMu]

Hallo,
und was spricht gegen meinen Vorschlag mit der Kalendertabelle? Damit hast Du alles erschlagen, musst noch nicht mal prüfen.
Und wenn Dateumsfelder zur Auswertung im Spiel sind, kann eine Kalendertabelle auch an anderer Stelle durchaus nützliche Hilfe sein.