Access-o-Mania

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

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

Hallo Herby,

ZitatDabei 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?

Zitatwenn 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.

Zitat1. 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

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

Zu Deiner Antwort:

ZitatKannst 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.

ZitatDa 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.

ZitatFü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

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

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

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

Hallo,

ZitatDabei 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....

Zitatoder 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....

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  8)

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.

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?!?

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

Hallo,

Zitat von: Herby49 am Dezember 22, 2011, 12:35:35Aber 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.

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

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.

Es spricht nichts dagegen, außer dass ich halt eine relativ große Tabelle mit in der DB habe und - wenn ich's richtig in Erinnerunghabe - kommt bei einer Fehleingabe auch wieder eine Access-Meldung in der Art: "Ihre Auswahl ist kein Element dieser Liste" (oder so ähnlich).
Aber vielleicht probier ich über die Feiertage doch mal vorurteilsfrei beide Varianten.

Gruß
Herby

Hallo,

Zitatkommt bei einer Fehleingabe auch wieder eine Access-Meldung in der Art: "Ihre Auswahl ...

Die kannst Du problemlos abfangen, mit einem Hinweis der passt.
Aber ein Kombifeld verfeinert sich mit jedem Tastendruck automatisch, sodass Falscheingaben relativ unwahrscheinlich werden.
Ein Tabelle für 100 Jahre sind gerade mal 146KB an Daten. Das ist ja nun nicht die Welt.

Und nicht zuletzt, kann diese Hilfstabelle auch an anderer Stelle durchaus sehr nützlich sein.

okay, das ist ein Argument. 146 KB ist wirklich nicht die Welt.
Vielen Dank

Gruß
Herby

Ohne das ich jetzt Lexware kenne oder das Datepickercontrol aus acc2010, aber evtl. arbeitet lexware mit 2 controls, dem Datepicker nur mit dem dropdown und einer separaten Textbox. in dieser Textbox kannst du dann alles mögliche eingeben ohne das die das dtPickercontrol in die quere kommt. und in die textbox ereignisse codierst du dann deine datumsvalidierung.

Hallo,

Zitatund in die textbox ereignisse codierst du dann deine datumsvalidierung.

Aber genau die Datumsvalidierung ist ja das Problem.
Man kann ohne großen Aufwand in Access kein Datum wirklich auf Gültigkeit prüfen.
Die Funktion IsDate nimmt z.B. sowohl 31.12.2011 als auch 12.31.2011 als gültig an. Und das gilt ja für viele Datumseinträge.

30.6.2011 = gültig
6.30.2011 = gültig
6.31.2001 = ungültig
31.6.2011 = ungültig

Um das Datum wirklich als gültiges Datum im deutschen Format zu prüfen, muss man eine eigene Funktion anlegen, die das Datum zerlegt und prüft. dabei ist auch das Schaltjahr zu berücksichtigen.

Hallo

Zitat von: MzKlMuAber genau die Datumsvalidierung ist ja das Problem.

dem widerspreche ich ja nicht. Ich nahm nur bezug auf den Vergleich mit lexware, ich weis nicht wie der in gecodet wurde, ob die ihren eigenen DTP erstellt haben oden den von MS genommen haben. Den DTP den ich kenne ( also den von MS aus den Commons, ich weis jetzt nicht ob der DTP in Acc2010 was anderes ist ) mach genau das was er soll, den Benutzer dazu zwingen ein richtiges Datum einzugeben. Auch weis ich nicht welche verkürzten Schreibweisen das LxW-dingens akzeptiert, yyyymmdd, ddmmyyyy, dmyy etc... und noch richtig nervend die amerikanische schreibweise mmddyyyy etc
Weil ich irgenwie rauslas das Herby in seinen Datumsfeld das DTP als auch gewisse Freiheitsgrade bezüglich der eingabe eingebaut haben wollte hab ich den Vorschlag mit den 2 Controls gemacht. Die Validierung wollte Herby ja dann mit mit VBA selbst realisieren.

Hallo zusammen
Das "Lexware-Dings" scheint mir ein einziges Control zu sein, weil der Datumspicker verborgen ist und erst dann erscheint, wenn man in das Feld klickt (klar, könnte auch die Eigenschaft "Visible/invisible" nutzen. Sieht zumindest gut aus. Und das datum wird sehr gut validiert

010112 wird zu 01.01.2012  (richtig)
29.02.11 wird zu 29.02.2011 aber das Datum wird mit einer Meldung als falsch ausgewiesen.

Zum Code:
Klar ist da Aufwand vonnöten, aber den will ich ja betreiben z.B. in der Form, dass
geprüft wird, ob nur Ziffern und ".", "," und "-" enthalten sind  -> sonst e falsch
Länge >= 6 Zeichen
Falls 6 Zeichen: Datumstrennzeichen setzen, aus den letzten beiden Ziffern eine 4stellige Zahl machen
Kommata als Trennzeichen durch den Punkt ersetzen.
Der Programmieraufwand dürfte sich in Grenzen halten.
Aber weil eh Access eine Fehlerbehandlung beim Format Datum nicht zulässt, werde ich wohl den Vorschlag mir der Datumstabelle realisieren.
Schade eigentlich, aber ih werde es schon überleben.

Liebe Grpße und Dank an alle, die sich den Kopf zerbrochen haben und Frohe Festtage

Herby