"oldValue"-Eigenschaft funktioniert reproduzierbar fehlerhaft bei erster Verwendung
Hans-Juergen Mauser
in einer Ereignisprozedur für "AfterUpdate" eines Kombinationsfeldes
möchte ich die Eigenschaft "oldValue" benutzen, um in bestimmten
Fällen den geänderten Wert zu verwerfen und zum Originalwert
zurückzukehren, wie das auch für "oldValue" beschrieben ist.
Allerdings funktioniert dies nicht zuverlässig - wenn das Formular
frisch geöffnet ist und zum ersten Mal dieses Feld in einem beliebigen
Datensatz geändert wird, wird der ursprüngliche Wert des Feldes
ignoriert. OldValue ist dann stattdessen gleich dem neu eingegebenen
Wert, der ursprüngliche ist nicht mehr verfügbar.
Ich habe den Wert an mehreren Stellen überprüft - beim Ereignis
"BeforeUpdate" stimmt er noch mit dem Ursprungswert überein, hat aber
plötzlich bei "AfterUpdate" den neuen (und eigentlich wieder zu
entfernenden) Wert des Feldes!
Wenn dies einmal vorgekommen ist, funktioniert es in allen
Wiederholungsfällen - egal ob am gleichen oder an einem anderen
Datensatz - problemlos.
Muß hier eventuell noch ein zusätzlicher Status überwacht werden, oder
ist das ein Fehler von Access selber?
Danke für jeden Hinweis und Gruß,
H.-J. Mauser
Emilia Maxim
Hallo Hans-Jürgen,
>in einer Ereignisprozedur für "AfterUpdate" eines Kombinationsfeldes
>möchte ich die Eigenschaft "oldValue" benutzen, um in bestimmten
>Fällen den geänderten Wert zu verwerfen und zum Originalwert
>zurückzukehren, wie das auch für "oldValue" beschrieben ist.
>Allerdings funktioniert dies nicht zuverlässig - wenn das Formular
>frisch geöffnet ist und zum ersten Mal dieses Feld in einem beliebigen
>Datensatz geändert wird, wird der ursprüngliche Wert des Feldes
>ignoriert. OldValue ist dann stattdessen gleich dem neu eingegebenen
>Wert, der ursprüngliche ist nicht mehr verfügbar.
>
>Ich habe den Wert an mehreren Stellen überprüft - beim Ereignis
>"BeforeUpdate" stimmt er noch mit dem Ursprungswert überein, hat aber
>plötzlich bei "AfterUpdate" den neuen (und eigentlich wieder zu
>entfernenden) Wert des Feldes!
Ja, das steht auch in der Hilfe (wobei ich im deutschen Text bei der
Gelegenheit einen Fehler entdeckt habe):
"Bei gebundenen Steuerelementen wird die Einstellung der Eigenschaft
OldValue (hier falsch in der Hilfe: BeforeUpdate) erst dann auf den
aktualisierten Wert gesetzt, nachdem das Ereignis AfterUpdate
eingetreten ist. Selbst wenn der Benutzer in das Steuerelement einen
neuen Wert eingibt, wird die Einstellung der Eigenschaft OldValue erst
geändert, wenn die Daten gespeichert sind (der Datensatz aktualisiert
ist). Wenn Sie die Aktualisierung unterbinden, wird der im
Steuerelement vorhandene Wert durch den Wert der Eigenschaft OldValue
ersetzt."
>Muß hier eventuell noch ein zusätzlicher Status überwacht werden, oder
>ist das ein Fehler von Access selber?
Verwende für Prüfungen das BeforeUpdate Ereignis. Wenn die Eingabe
nicht stimmt, Cancel auf True setzen, den Rest erledigt Access. Wenn
mehrere Daten voneinander abhängig sind, verwende das BeforeUpdate
Ereignis des Formulars.
Gruß
Emilia
Emilia Maxim
PC-SoftwareService
Stuttgart
http://www.maxim-software-service.de
Mike Fried
ich mache zu weilen das selbe und es funktioniert eigentlich problemlos.
z.B.
Private Sub .cmb_Feld1_AfterUpdate()
Me.cmb_Feld1 = Me.cmb_Feld1.OldValue
End Sub
Da muss was anderes dahinter stecken. Was passiert vor dem Zurücksetzen?
Gruß Mike
Hans-Juergen Mauser
Emilia Maxim <In...@maxim-Software-Service.de> wrote in message news:<gbo5gvki3khpomfel...@4ax.com>...
> "Bei gebundenen Steuerelementen wird die Einstellung der Eigenschaft
> OldValue (hier falsch in der Hilfe: BeforeUpdate) erst dann auf den
> aktualisierten Wert gesetzt, nachdem das Ereignis AfterUpdate
> eingetreten ist. Selbst wenn der Benutzer in das Steuerelement einen
> neuen Wert eingibt, wird die Einstellung der Eigenschaft OldValue erst
> geändert, wenn die Daten gespeichert sind (der Datensatz aktualisiert
> ist). Wenn Sie die Aktualisierung unterbinden, wird der im
> Steuerelement vorhandene Wert durch den Wert der Eigenschaft OldValue
> ersetzt."
Das wäre ja auch in Ordnung, wenn oldValue erst beim Speichern des
Datensatzes geändert (also auf den "neuen" Wert) gesetzt würde. Aber
bei mir wird, wenn die Datensatzgruppe über das Formular gerade neu
geöffnet ist, beim ersten Mal dieser Fehler produziert, daß oldValue
schon _während_ dem AfterUpdate-Ereignis den neuen Wert annimmt.
> Verwende für Prüfungen das BeforeUpdate Ereignis. Wenn die Eingabe
> nicht stimmt, Cancel auf True setzen, den Rest erledigt Access. Wenn
> mehrere Daten voneinander abhängig sind, verwende das BeforeUpdate
> Ereignis des Formulars.
Das mach ich mittlerweile schon, zusätzlich noch ein
Steuerelement.undo - dann ist es komplett unabhängig vom Speicher-
bzw. Sperrzustand des Datensatzes. oldValue eignet sich dann womöglich
gut als Abbruch-Kriterium... aber trotzdem dürfte doch eigentlich
dieses "Problem" gar nicht auftauchen!?
Vielleicht noch zur Info: ist Access 2000 und alle Tabellen sind aus
einer externen Access-DB verknüpft. Datensatzsperrung auf
Formularebene ist "bearbeiteter Datensatz".
Vielen Dank und Grüße,
Hans-Jürgen Mauser
Hans-Juergen Mauser
unter welcher Access-Version arbeitest Du damit? Das hatte ich leider
vergessen zu erwähnen, daß es sich bei mir um Access 2000 handelt
"Mike Fried" <fr...@eudatabase.de> wrote in message news:<bdur4i$11bg1g$1...@ID-94473.news.dfncis.de>...
> ich mache zu weilen das selbe und es funktioniert eigentlich problemlos.
>
> z.B.
> Private Sub .cmb_Feld1_AfterUpdate()
> Me.cmb_Feld1 = Me.cmb_Feld1.OldValue
> End Sub
>
> Da muss was anderes dahinter stecken. Was passiert vor dem Zurücksetzen?
Zu Testzwecken ist da erstmal gar nix passiert, nur noch ein
Meldungsfenster war dazwischen (vor der eigentlichen
Rücksetzanweisung). Aber das sollte doch keinen Einfluß haben!?
--
Jetzt habe ich gerade nochmal getestet, nun scheint es doch zu gehen -
seltsam, dann war es wohl doch mal wieder ein "einzelner" Ausfall, wie
ich ihn neulich auf andere Weise schon hatte, als eine Abfrage
irgendwelche Hieroglyphen in manchen Feldern zeigte, von denen in der
Tabelle nichts zu sehen war :-(
Oder als die Fehlermeldung 3020 "Update oder Cancel.Update ohne Edit"
sporadisch und nicht reproduzierbar erschien, obwohl nirgendwo die
Update-Methode angewandt wurde... und nach leichtem Umschreiben der
bemängelten Prozedur, was aber nur das Ersetzen von Variablen war,
gings dann plötzlich wieder...
Muß man mit sowas eigentlich generell leben bei Benutzung von Access?
Das ist sehr frustrierend, wenn man eigentlich Fehlersuche in den
eigenen Programmierungen macht, und dann zum Teil durch solche
"Überraschungen" nach Fehlern sucht, die man eigentlich gar nicht
gemacht hat!?
Trotz allem vielen Dank und Grüße,
Hans-Jürgen Mauser
Mike Fried
> Zu Testzwecken ist da erstmal gar nix passiert, nur noch ein
> Meldungsfenster war dazwischen (vor der eigentlichen
> Rücksetzanweisung). Aber das sollte doch keinen Einfluß haben!?
>
> --
>
> Jetzt habe ich gerade nochmal getestet, nun scheint es doch zu gehen -
> seltsam, dann war es wohl doch mal wieder ein "einzelner" Ausfall, wie
> ich ihn neulich auf andere Weise schon hatte, als eine Abfrage
> irgendwelche Hieroglyphen in manchen Feldern zeigte, von denen in der
> Tabelle nichts zu sehen war :-(
> Oder als die Fehlermeldung 3020 "Update oder Cancel.Update ohne Edit"
> sporadisch und nicht reproduzierbar erschien, obwohl nirgendwo die
> Update-Methode angewandt wurde... und nach leichtem Umschreiben der
> bemängelten Prozedur, was aber nur das Ersetzen von Variablen war,
> gings dann plötzlich wieder...
> Muß man mit sowas eigentlich generell leben bei Benutzung von Access?
> Das ist sehr frustrierend, wenn man eigentlich Fehlersuche in den
> eigenen Programmierungen macht, und dann zum Teil durch solche
> "Überraschungen" nach Fehlern sucht, die man eigentlich gar nicht
> gemacht hat!?
offensichtlich gibt es Fehler für die der Entwickler nichts kann :-( Geht
mir auch öfter so. Krasses Beispiel an dem ich vorige Woche fast verzweifelt
währ : Speichererweiterung von 256 auf 512 MB - nichts schlimmes, aber in
einer DB funktioniert ein ganzes Form nicht mehr. Nach der Konvertierung in
A2k geht es wieder - nach der Rückkonvertierung in A97 geht es nicht mehr
:-( Speicher wieder raus (allerdings erst 2 Stunden später....) alles
funktioniert. Das kann man auch nicht erklären - oder?
Lass Dich nicht von MS unterkriegen.
Gruß Mike
Jörg Ackermann
>Das kann man auch nicht erklären - oder?
Doch ! Kann man !
Bei RAM-Einbau immer zuerst verwenden !
Gruß
Hans-Juergen Mauser
jetzt mal noch ne andere Frage, worüber ich bisher viele, aber vor
allem viele unbrauchbare Informationen gefunden habe, nämlich zur
Datensatzsperrung.
Folgende Konstellation:
- Anwendung in einer MDB-Datei, Tabellen verknüpft aus anderer
MDB-Datei
- ein Formular, dessen Datensatzsperrung auf "bearbeiteter Datensatz"
steht
- eine Prozedur, die beim Ändern eines Feldes im Formular
(BeforeUpdate) alle Datensätze AUSSER (!) dem im Formular geöffneten
durchsucht und ggf. in diesen ANDEREN Datensätzen Werte ändert
- die Option "DB mit Sperrung auf Datensatzebene" in
Extras/Optionen... ist aktiviert
- die Datensätze der betreffenden Tabelle sind sehr klein (~ 10 Byte)
Wenn das Formular, wie gesagt, bei der Sperrung auf "bearbeiteter
Datensatz" steht, ist es nicht möglich, die Prozedur durchzuführen -
zu Beginn der Edit-Methode kommt ein Fehler 3188, Datensatz bereits
gesperrt.
Warum? Es werden ausdrücklich als Datenquelle innerhalb der Prozedur
nur die Datensätze geöffnet (SQL-Abfrage/Dynaset), die nicht der
aktuelle Datensatz des Formulars sind.
Es wird viel geschrieben über die Speicherseiten-Größe von 2 oder 4
KB, die Access üblicherweise sperrt, aber es wird auch gesagt, daß das
durch die obengenannte Option unter "Extras/Optionen" aufgehoben
werden könnte.
Wenn ich versuche, die Datensätze im Hintergrund von Hand zu
bearbeiten, während einer durch das Formular "gesperrt" ist, ist das
möglich - warum daher nicht in der Prozedur?
Es geht nur dadurch, daß ich die Sperrung des Formulars ganz
deaktiviere, was mir aber nicht wohl ist, wenn das Ding nachher im
Betrieb unter mehreren Benutzern läuft. Theoretisch könnten da
Inkonsistenzen auftreten, die ich vermeiden will.
Weißt Du oder jemand anderes dazu einen guten Rat?
> Lass Dich nicht von MS unterkriegen.
Oder ist das das einzige, was als "Erklärung" bleibt?
Viele Grüße und danke,
Hans-Jürgen Mauser
Michel Fouquet
es wäre natürlich ausgesprochen übersichtlich, für ein neues Thema auch
einen neuen Thread zu beginnen. Zum Thema Record Level Locking sind
folgende Artikel aus der MSKB bzw. MSDN hilfreich (bei den Links ggf.
den Zeilenumbruch des Newsreaders beachten):
ACC2000: Record-Level Locking Does Not Appear to Work
http://support.microsoft.com/default.aspx?scid=kb%3ben-us%3b225926
Page-Level Locking vs. Record-Level Locking
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odeopg/
html/deovrpagelevellockingvsrecordlevellocking.asp
PRB: Jet 4.0 Row-Level Locking Is Not Available with DAO 3.60
http://support.microsoft.com/default.aspx?scid=kb%3ben-us%3b306435
Locking Shared Data by Using Recordset Objects in VBA
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odeopg/
html/deovrlockingshareddatabyusingrecordsetobjectsinvba.asp
Z.B. gilt:
"However, any SQL Data Manipulation Language (DML) queries that is,
queries that add, delete, or modify records that are run from ADO (when
you use the Microsoft Jet 4.0 OLE DB Provider), DAO, or the Access query
user interface will use page-level locking. Page-level locking is used
for SQL DML statements to improve performance when you are working with
many records. However, even when record-level locking is turned on, it
is not used for updates to values in memo fields and values in fields
that are indexed they still require page-level locking."
Naja, ist nicht so ganz mein Thema. Daher: Viel Vergnügen bei der
Lektüre und der Vermehrung der gewonnenen Einsichten!
mfg,
Michel
Hans-Juergen Mauser
den Thementitel habe ich geändert... das hatte ich leider aus Eile
vergessen ;-)
Danke für die Hinweise zu den Microsoft-Texten, aber leider
funktioniert es trotzdem nicht - obwohl es das eigentlich müßte, auch
gerade nach der Lektüre dieser Texte. Es wird darauf hingewiesen, daß
beim Bearbeiten indizierter Felder - wider allen Einstellungen - die
seitenweise Sperrung benutzt wird. Allerdings bearbeite ich per
Prozedur nur ein nichtindiziertes Feld, und trotzdem wird dabei
versucht, eine Seite zu sperren (was in meinem Fall schon die ganze
Tabelle ist - numerische Zuordnungen...)
Die Datensatzsperrung des Formulars ist korrekt, das habe ich
nachgeprüft. Aber aufgrund des einen, durch das Formular gesperrten
Datensatzes kann die "komplette" Sperrung danach nicht durchgeführt
werden, was den Programmablauf scheitern läßt.
Zur "Behebung" könnte ich die Sperrung durch das Formular komplett
deaktivieren - aber das wird (mir zu) kritisch, sobald mehrere
Benutzer daran arbeiten.
Ich werde mal noch versuchen, genau zu verfolgen, was durch die
Prozedur versucht wird zu sperren.
Könnte das Problem unter Umständen an den verknüpften Tabellen liegen,
die in einer anderen MDB-Datei liegen?
Vielen Dank und Grüße,
Hans-Jürgen Mauser
"Michel Fouquet" <ora...@wanadoo.fr> wrote