OnBeforeRecordChange-Ereignis???

19/02/2008 - 10:15 von Thomas Winkler | Report spam
Hi,

ich habe ein HFo, mit DataEntry = True, in welches Daten in mehrere UFOs
eingegeben werden. Die Daten der UFOs stehen in Beziehung zueinander,
welche jedoch nicht im Schema zu realisieren sind (Summengeleichheit, z.
B.). Der Nutzer kann beliebig zwischen den UFOs hin und herwechseln.
Beim Verlassen der HFos oder DS-Wechsel mittels eigener Buttons stellt
eine check()-Funktion sicher, dass dies nur erlaubt wird, wenn die
aktuellen Eingaben auch konsistent sind.

Soweit so gut. Wenn jetzt ein Benutzer den DS im HFo per

1. integrierten Navi-Schaltflàchen unten im Formular oder
2. Mausrad oder
3. Strg+F

wechselt, findet diese Prüfung nicht statt.

Ergebnis: Es könnten inkonsistente Daten eingegeben, zu einem
Konsistenten DS gewechselt und danach das Form ohne Fehler verlassen werden.

Habe leider kein passendes Ereignis gefunden, welches VOR dem DS-Wechsel
auftritt und sich noch abbrechen làßt (Cancel = true).

Gibt's dafür doch noch ein Ereignis?
Oder einen sonstigen Workaround (API)?
Ist die Herangehensweise evtl. falsch?

Thomas

P.S.: BeforeUpdate scheidet aus, da die Daten vorher schon gespeichert sind.

"Access? Damit arbeite ich nicht. Das ist doch nur ein abgespecktes Excel."
 

Lesen sie die antworten

#1 Henry Habermacher
19/02/2008 - 11:28 | Warnen spam
Hallo Thomas

Thomas Winkler wrote:
Soweit so gut. Wenn jetzt ein Benutzer den DS im HFo per

1. integrierten Navi-Schaltflàchen unten im Formular oder
2. Mausrad oder
3. Strg+F

wechselt, findet diese Prüfung nicht statt.

Ergebnis: Es könnten inkonsistente Daten eingegeben, zu einem
Konsistenten DS gewechselt und danach das Form ohne Fehler verlassen
werden.
Habe leider kein passendes Ereignis gefunden, welches VOR dem DS-Wechsel
auftritt und sich noch abbrechen làßt (Cancel = true).

P.S.: BeforeUpdate scheidet aus, da die Daten vorher schon gespeichert
sind.



Da bist Du falsch informiert. Das Form_BeforeUpdate Ereignis ist genau das
Ereignis, das anlàuft, bevor die geànderten Daten im Recordset in die
Datenbank geschrieben werden. Dieses Ereignis ist speziell dafür geeignet,
via Cancel = True abgebrochen zu werden, um den Update in die Datenbank zu
verhindern. Dieses Ereignis wird selbst bei Recordwechsel oder beim Befehl
Me.Dirty=False angeworfen. Ich habe noch keinen Fall gefunden, bei dem das
nicht so wàre und all meine Anwendungen basieren auf diesem Ereignis, wenn
Eingabekonsistenzprüfungen notwendig sind.

Wie kommst Du darauf, dass die Daten vorher schon gespeichert sind?

Gruss
Henry



SEK2 Anmeldung: http://donkarl.com/?SEK
Microsoft MVP Office Access
Keine E-Mails auf Postings in NGs. Danke.
Access FAQ www.donkarl.com

Ähnliche fragen