Hallo Henry,
Post by Henry Habermacher [MVP Access]Hallo Michael
Verstehe ich richtig: Du hast Dir sowas wie eine Kopie des Recordsets
angelegt, welche Du dann wieder brauchst, wenn Du die Daten wieder
zurücksetzen willst. Wie ist dieses Recordset definiert. Ist es ein Snapshot
oder ein Dynaset? Falls es ein Dynaset ist, dann könnte das durchaus
dazwischenfunken. Das kann man aber nur sagen, wenn man das genau vor sich
hat und untersucht.
Ich erstelle keine Kopie des des Recordsets, sondern im Klickereignis der
jeweiligen Buttons ein neues mit einem SQL-Statement als Quelle, in dem die
Werte des angezeigten Datensatzes in der WHERE-Klausel enthalten sind. Die
Datensätze der geänderten Tabelle werden über ein Attribut als geändert
gekennzeichnet, so dass die Buttons für das Verwerfen verschiedener
Änderungen im Current-Ereignis bei Bedarf aktiviert werden. Am Ende der
jeweiligen Prozedur wird dann mit requery die Datenbasis aktualisiert.
Post by Henry Habermacher [MVP Access]Wie machst Du das dann später, wenn der
Datensatz, der ja gespeichert wurde, wieder zurückgesetzt werden soll? Liest
Du beim Requery nicht auch gleichsam den Datensatz neu in die - nennen wir
sie mal Schattenkopie - ein?
Die Tabelle enthält Daten zu Analysemethoden, die für einen bestimmten
Zeitraum verwendet wurden. Anhand des Probenahmedatums kann beim Datenimport
und der manuellen Dateneingabe ermittelt werden, welche Methode den Daten
zuzuordnen ist. Ändert sich die Methode, muss dass in dieser Tabelle mit dem
Datum festgehalten werden. Die Änderungen sind daher auf wenige Möglichkeiten
beschränkt, z.B. Datensatz für neue Methode mit Anfangsdatum einfügen und
Enddatum der bisherigen Methode einfügen. Über die o. g. Datensatzmarkierung
und den sonstigen Daten der Tabelle kann der alte Zustand wieder hergestellt
werden.
In anderen Fällen habe ich aber auch mit ungebundenen Recordsets gearbeitet,
in die die Daten beim Laden eingelesen werden. Über die Schlüssel lassen sich
die Datensätze dann zuordnen und die Daten wieder zurückschreiben.
Aber nun zur Lösung des Problems. Die Datenquelle des Formulars ist nicht
die zu ändernde Tabelle, sondern ein SQL-Statement. Dieses enthält ein ORDER
BY mit dem Primary Key. Da das Formular aus der Zeit vor der Migration auf
den SQL Server stammt, fehlte natürlich die TOP-Angabe. Das hindert Access
aber nicht daran, die Daten wie gewünscht anzuzeigen, sondern führt nur zu
dem besagten Verhalten bei der Datenänderung. Nach der Korrektur des
SQL-Statements läuft alles wie gewünscht.
Vielen Dank noch mal.
Michael