Office: (Office 2010) Inhalt un-/gebundener Textfelder erst nach Klick auf "Speichern"

Hallo, ich bin's nochmal... das Thema ist leider noch nicht ganz erledigt: *frown.gif*

Habe auf dem Formular ja 2 Schaltflächen: Speichern und Abbrechen. Bei Klick auf Speichern wird auch gespeichert und bei Klick auf Abbrechen wird das ganze verworfen. Code:

Wenn ich aber nun die Textfelder beschreibe und dann das Formular schließe, kommt zwar noch eine Messagebox aus meiner Pflichtfeldüberprüfung, wenn nicht alle Pflichtfelder geprüft werden, aber der unvollständige Datensatz wird trotzdem in der Tabelle gespeichert. Gleiches passiert wenn ich von der Formularansicht in die Layout- oder Entwurfsansicht wechsel.

Hierzu mal mein VBA-Code aus dem BeforeUpdate-Ereignis des Formulars:
Code:

Anbei nochmal der VBA-Code aus dem Speichern-Button:
Code:

Hab jetzt schon mit mehreren Formularereignissen und [Me.Undo] versucht dieses ungewollte Speichern aufzuhalten. Dazu habe ich bisher folgende Ereignisse getestet: "Beim Schließen", "Bei Entladen", "Bei Ansichtänderung"
Das hat aber alles nichts gebracht.

Was kann ich jetzt noch machen um sowas zu verhindern? Klar: in den Entwurfsmodus wird der Anwender später nicht mehr wechseln können, das Formular wird er aber schließen [X] können und so unbeabsichtigt die Daten in der gebundenen Tabelle speichern

 

Was zu verhindern ist per
Code:

 

Hallo, danke für die schnelle Antwort Maxel, meinst du also einfach das "Kreuz" [X] sperren damit der Anwender dann auf abbrechen klicken muss um das Formular zu schließen?! Aber was passiert dann wenn der Anwender dann einfach Access schließt?

 

Hallo FelySN89!

Wenn Tabellenfelder kluge Initialwerte haben, so kannst Du Dir eine diesbezügliche Prüfung überhaupt ersparen.
ZB bei Anrede den Wert für "Sehr geehrter Herr" vorgeben.
Damit steht zumindest ein gültiger Wert in diesem Kombifeld, auch wenn er zunächst falsch sein kann. Das Verklicken des Anwenders kannst Du schließlich auch nicht verhindern.

Dann würde ich eine Prüffunktion schaffen, die als Parameter die zu prüfenden Controls enthält. Was zu prüfen ist, hast Du ja schon codiert.
Sie liefert einen additiven binären Fehlercode (Fehlercode Or 1 (oder 2, 4) je nach Feld) etc. den Du anschließend prüfen kannst, willst Du die Meldungsbox im Fehlerfall nicht in der Funktion ausgeben.
Außerdem wäre es besser, nicht für jedes fehlerhafte Feld sofort eine Meldungsbox auszugeben, sondern alle Felder auf einmal zu prüfen und alle Fehler in einer einzigen Box auszugeben. Also ohne ElseIf. Das nervt den Anwender weniger, hat er sich öfter vertan.

In BeforeUpdate setzt Du Cancel vorne weg auf True.
Dann rufst Du die Prüffunktion immer auf.
Im Falle die Funktion einen Wert = 0 returniert löscht Du Cancel.
Me.Undo würde ich nicht verwenden. Und die Klimmzüge mit Me.Dirty sind auch nicht nötig.
Damit erzwingst Du ziemlich verläßlich eine gültige Neuanlage eine Datensatzes,
es sei denn der Anwender cancelt das Form, die DB oder Access, oder der PC bzw. die Netzwerkverbindung stürzt ab.

Ich kenne Entwickler, die verwenden deshalb grundsätzlich keine gebundenen Formulare. Erst mit einem Save-Button wird gesichert. So wie Du es ursprünglich vorgesehen hast.
Schlimmstenfalls fehlt im Falle von Netzwerkstörungen, und Access ist da sehr heikel, oder anderen nicht beeinflußbaren Ereignissen nur diese eine Eingabe.
Ich gehöre nicht wirklich zu solchen. Nur in Ausnahmefällen, um Inkonsistenzen verläßlich und einfach zu vermeiden.

Darum ist auch ein Datumsfeld LetzteAenderung in Tabellen von Vorteil, welches dann aktualisiert wird, wenn die Änderung/Neuanlage erfolgreich war.
(donkarls Access-Seiten zweite Variante) Für so ein Feld daher keinen Standardwert Jetzt() vorsehen.

Leider läßt sich Spaghetticode bei Prüfungen nicht wirklich verhindern.
Aber Prüfungen wie IsNull(txtNachname) entfallen dann, wenn Du in der Tabellendefinition "Eingabe erforderlich" auf Ja und "Leere Zeichenfolge" auf Nein setzt.

Wolfgang.

Ich bin fast sicher, daß mir einige jetzt widersprechen werden, aber mir geht es in erster Linie nicht um einen
raffiniert ausgefeilten, fehler- und makellosen Beitrag, sondern um Denkanstöße.

 

Das mit Cancel = True habe ich wie bei donkarls Access-Seiten bereits versucht, führte aber stets zu einer Fehlermeldung ("Variable nicht definiert"). Mal so nebenbei: WAS genau bewirkt Cancel = True?!

Die Pflichtfeldüberprüfung mag so zwar umständlicher sein, aber gefällt mir in meiner Version besser als dein Vorschlag. Falsche Eingaben für Felder wie zum Beispiel "Anrede" werden mittels vorgegebener Werteliste aus einem Kombifeld gewählt, also ist bei solchen Dingen keine Falscheingabe möglich. Felder wie Vorname/Nachname können nicht sinnvoll überprüft werden auf Falscheingabe, nur auf Eingabe...

 

Ja, das "Kreuz" sperren - kannst Du per VBA machen oder einfach im Formularentwurf "Schließen Schaltfläche" auf NEIN setzen. Wie Du alternativ das Formular schließen lässt, ist Dir überlassen. Ein eigener Schließen-Button kann den gewünschten Code aufnehmen.

Auch das lässt sich per Code vermeiden.

 

Hallo FelySN89!

Du gehst nicht auf meine Anregung betr.
"Eingabe erforderlich" und "Leere Zeichenfolge"
ein.
Warum nicht?
Damit Du nachher auf IsNull prüfen mußt?

Falscheingabe nicht, aber überhaupt eine.
Warum enthält Dein Code dann
If IsNull(cboAnrede) Then
Doch nur, weil das zugehörige Tabellenfeld keinen Initailwert enthält!
Und nur davon haben ich geschrieben.

Sprichwort: Jeder Fuchs lobt seinen eigenen Schwanz.
Aber nach jedem Fehler zurück zum Formular zu gehen
um dann ev. die nächste Fehlermeldung anzuzeigen, statt alle auf einmal,
wirst Du, wenn Dein Code bleibt wie er ist, nicht zustande bringen.

Cancel = True verhindert das Speichern der Daten eines Forms.
Egal ob bei einer Neuanlage oder Änderung.
Me.Undo verwende ich deswegen nie, damit die übrigen
getätigten Eingaben im Form erhalten bleiben.

Wolfgang