<\/p>\n
Wenn mehrere Benutzer mit den Daten einer Datenbank arbeiten, möchten Sie für die relevanten Tabellen vielleicht nachhalten, wer wann welchen Datensatz angelegt, bearbeitet oder gelöscht hat. Dazu sind zwei Schritte nötig: Das Hinzufügen der Felder zum Speichern dieser Informationen in den relevanten Tabellen und das Eintragen dieser Informationen, wenn es soweit ist. Dieser Beitrag zeigt, wie Sie mit minimalem Aufwand ein solches Protokoll einrichten. <\/b><\/p>\n
Eine detaillierte Historie der änderungen an Daten samt Archivierung der Daten vor jeder änderung ist aufwendig und wird nur selten benötigt. Häufiger trifft man den Fall an, dass man einfach nur wissen möchte, wer zum Beispiel einen Kunden angeleg oder wer eine Bestellung zuletzt geändert oder gelöscht hat.<\/p>\n
Beim Anlegen und Bearbeiten der Daten ist dies gar kein Problem: Sie fügen der Tabelle einfach je zwei Felder zum Speichern des Datums der Aktion und des Mitarbeiters hinzu und sehen an den entsprechenden Stellen, also beispielsweise in den Formularen zur Bearbeitung dieser Daten, die benötigten Codezeilen zum Eintragen der änderungsdaten vor.<\/p>\n
Beim Löschen wird dies schon schwieriger: Wo wollen Sie ein Löschdatum und einen Verweis auf den Verantwortlichen unterbringen, wenn der Datensatz anschließend nicht mehr vorhanden ist Ganz einfach: Sie löschen den Datensatz gar nicht, sondern versehen ihn mit einem Marker.<\/p>\n
So können Sie auch das Löschdatum und den löschenden Mitarbeiter ganz einfach hinzufügen. Dass der Datensatz ja nun gar nicht physisch gelöscht ist, ist zwar kein Problem, bringt aber ein wenig zusätzlichen Aufwand mit sich: Alle Abfragen, Formulare, Berichte, Steuerelemente und Codeabschnitte, die sich auf die Daten der Tabelle mit den vermeintlich gelöschten Datensätzen beziehen, müssen um eine entsprechende WHERE<\/b>-Klausel ergänzt werden, die alle Datensätze ausschließt, für die der Wert eines Feldes etwa mit dem Namen GeloeschtAm <\/b>nicht Null ist.<\/p>\n
Im Gegenzug können Sie aber auch später noch auf die Daten zugreifen, die bereits gelöscht wurden – beispielsweise, um diese entgültig zu löschen, zu archivieren oder um Auswertungen auf den gesamten Datenbestand zu fahren.<\/p>\n
Tabellen anpassen<\/b><\/p>\n
Wie üblich möchten wir den Aufwand zum Einbau dieser Lösung möglichst gering halten. Das betrifft zum Beispiel das Hinzufügen der Felder mit den änderungsdaten zu den betroffenen Tabellen.<\/p>\n
Normalerweise öffnet man jede dieser Tabellen im Entwurf, fügt die gewünschten Felder hinzu, verknüpft diese gegebenenfalls mit einer Mitarbeitertabelle, um sich per Fremdschlüssel auf die ausführenden Mitarbeiter beziehen zu können, und speichert dann die Tabelle.<\/p>\n
Und das erledigt man nicht nur für eine, sondern für alle Tabellen, deren änderungsdaten protokolliert werden sollen.<\/p>\n
Puh, das ist aber langweilig – da setzen wir uns doch lieber mal ein paar Minuten hin und programmieren eine kleine Funktion, die uns diese Aufgabe abnimmt.<\/p>\n
Voraussetzung für die nachfolgend beschriebene Prozedur ist eine Benutzertabelle und die Anmeldung der Benutzer beim Start der Datenbank. Für Beispielzwecke soll diese möglichst einfach aussehen – zum Beispiel wie in Bild 1.<\/p>\n
![\"pic001.png\"](\"..\/fileadmin\/_temp_\/2009_04\/Aenderungshistorie-web-images\/pic001_opt.jpeg\")
<\/p>\n
Bild 1: Diese Tabelle soll in den Feldern zum Eintragen der änderungen per Fremdschlüssel referenziert werden.<\/span><\/b><\/p>\n Die änderungsfelder legen wir mit einigen SQL-Anweisungen an, die wir mit der Execute<\/b>-Methode des Database<\/b>-Objekts ausführen. Werfen wir zunächst einen Blick auf die nackten SQL-Anweisungen. Die erste soll einfach nur ein Datumsfeld namens AngelegtAm <\/b>hinzufügen und sieht so aus:<\/p>\n Sie können diese Anweisung ausprobieren, indem Sie eine neue, leere Abfrage im Entwurf öffnen und dann zur SQL-Ansicht wechseln. Dort tragen Sie den SQL-Ausdruck ein und führen ihn aus.<\/p>\n Wir brauchen noch zwei weitere Anweisungen, von denen die erste das Feld zum Speichern des durchführenden Benutzers anlegt und das zweite die Beziehung von diesem Fremdschlüsselfeld zur Tabelle tblBenutzer<\/b>:<\/p>\n Zusammengefasst in einer Funktion sehen die SQL-Anweisungen wie in Listing 1 aus. Der Aufruf für unsere Beispielkonstellation mit einer Tabelle tblBenutzer<\/b> für die Benutzerdaten und mit einer Tabelle tblKunden<\/b>, die die Felder zum Eintragen der änderungsdaten erhalten soll, sieht so aus:<\/p>\n Listing 1: Hinzufügen von History-Feldern zu einer Tabelle<\/p>\n Verwenden Sie diesen Aufruf für alle Tabellen, für deren Datensätze Sie änderungsinformationen speichern möchten. Das Ergebnis sieht wie in Bild 2 aus. Was Sie hier nicht erkennen können, sind die Beziehungen, welche die Funktion aus Listing 1 zwischen den Fremdschlüsselfeldern AngelegtDurch<\/b>, ZuletztGeaendertAm<\/b> und GeloeschtAm <\/b>und der Tabelle tblBenutzer <\/b>anlegt. Abb. 3 liefert den Beweis, dass auch die Beziehungen ordnungsgemäß angelegt wurden.<\/p>\n Bild 2: Eine Beispieltabelle mit Feldern zum Speichern von änderungsinformationen<\/span><\/b><\/p>\n Bild 3: Diese Beziehungen wurden mit der Funktion aus Listing 1 angelegt.<\/span><\/b><\/p>\n Alternative Tabellenanpassung<\/b><\/p>\n Es gibt noch eine Alternative zur beschriebenen Vorgehensweise: Dabei würden Sie die sechs Felder zum Festhalten der änderungsinformationen nicht direkt in die Tabellen schreiben, sondern in eine separate Tabelle. Diese enthält neben den sechs Feldern noch zwei weitere Felder zum Speichern der Tabelle und des Datensatzes, auf die sich die Informationen beziehen.<\/p>\n Der Nachteil dieser Vorgehensweise ist, dass der Aufwand für das Herausfiltern von als gelöscht markierten Daten relativ hoch ist. Daher sehen wir an dieser Stelle von einer ausführlicheren Beschreibung dieser Variante ab.<\/p>\n änderungsdaten pflegen<\/b><\/p>\n Der nächste Schritt ist etwas aufwendiger: Sie müssen prüfen, an welchen Stellen der Datenbank Operationen auf Basis der Daten dieser Tabelle durchgeführt werden. Überall dort müssen Sie per Code oder über entsprechende änderungen an eventuell vorhandenen Aktionsabfragen dafür sorgen, dass bei änderungen auch die nötigen Informationen in die soeben angelegten Felder eingetragen werden.<\/p>\n Leichter haben Sie es, wenn Sie die Anwendung ohnehin gerade erst erstellen – Sie laufen dann weniger Gefahr, die Stellen, an denen die Daten geändert werden, zu übersehen.<\/p>\n Vielleicht ist das Ganze aber auch gar nicht so aufwendig. Gehen wir einmal von der Annahme aus, dass Sie Daten nur über Formulare, über die Execute<\/b>-Methode des Database<\/b>-Objekts oder per DAO mit AddNew<\/b>, Edit <\/b>und Update <\/b>ändern. Dann ergeben sich möglicherweise verallgemeinernde Vereinfachungen – aber schauen Sie doch selbst.<\/p>\n änderungsdaten in Formularen<\/b><\/p>\n In Formularen gibt es zwei Ereignisse, die beim Speichern eines neuen oder geänderten beziehungsweise beim Löschen eines Datensatzes ausgelöst werden. Das Ereignis Vor Aktualisierung <\/b>beispielsweise feuert immer beim Speichern eines geänderten Datensatzes, egal, ob es sich um einen neuen oder einen vorhandenen Datensatz handelt.<\/p>\n Zu Beispielzwecken legen Sie nun ein einfaches Formular an, das alle Felder der oben beschriebenen Tabelle tblKunden <\/b>enthält. Erstellen Sie dann eine Prozedur für die Ereigniseigenschaft Vor Aktualisierung<\/b>, die wie folgt aussieht:<\/p>\n Die Prozedur prüft, ob gerade ein neu angelegter (Me.NewRecord = True<\/b>) oder ein bestehender Datensatz geändert wurde und nun gespeichert werden soll. Im Falle eines neuen Datensatzes schreibt die Routine noch das aktuelle Datum samt Zeit in das Feld AngelegtAm<\/b>, bei einem vorhandenen Datensatz ist das Feld ZuletztGeaendertAm <\/b>das Ziel. Das ist alles – änderungen im Formular werden so zuverlässig protokolliert.<\/p>\n Betrachten wir nun das Löschen eines Datensatzes. Das Löschen löst das Ereignis Beim Löschen <\/b>aus, wofür Sie die folgende Routine hinterlegen:<\/p>\n <\/p>\n Die Routine stellt das Löschdatum des Datensatzes auf das aktuelle Datum samt Zeit ein, speichert den Datensatz (Me.Dirty = True<\/b>) und bricht den Löschvorgang ab, damit der Datensatz nicht wirklich gelöscht wird (sonst hätten wir wohl nichts vom frisch geänderten Löschdatum …).<\/p>\n Wenn Sie dies nun im Formular ausprobieren, werden Sie feststellen, dass diese Routine dummerweise auch das letzte änderungsdatum beeinflusst, denn das Eintragen des Löschdatums und das anschließende Speichern ist natürlich auch eine änderung, die vom Vor Aktualisierung<\/b>-Ereignis registriert wird.<\/p>\n Wir müssen der Routine Form_BeforeUpdate<\/b> also irgendwie mitteilen, dass sie das änderungsdatum beim Löschen eines Datensatzes und der damit verbundenen änderung des Datensatzes nicht berücksichtigt. Dazu führen wir die folgende formularmodulweit gültige Variable ein:<\/p>\n Sie soll vor dem Speichern des Datensatzes während des Löschvorgangs auf den Wert True <\/b>und anschließend wieder auf False <\/b>eingestellt werden:<\/p>\n Damit die Vor Aktualisierung<\/b>-Ereignisprozedur dies entsprechend verarbeitet, soll sie vor dem ändern des änderungsdatums prüfen, ob nicht vielleicht gerade ein Löschvorgang erfolgt und somit das änderungsdatum beibehalten werden soll:<\/p>\n Probieren Sie dies nun aus – es funktioniert. Aber auch nur fast: Der gelöschte Datensatz wird zwar durch den entsprechenden Eintrag im Feld GeloeschtAm <\/b>als gelöscht markiert, verschwindet aber nicht aus der Datenblattansicht.<\/p>\n Das liegt an zwei Dingen: Erstens haben wir die Datenherkunft noch gar nicht entsprechend eingestellt, das heißt, dass einfach alle Datensätze der Tabelle tblKunden <\/b>angezeigt werden.<\/p>\n Zweitens würde es selbst dann nicht funktionieren, weil die Datenherkunft während des Löschens eines Datensatzes nicht aktualisiert werden kann.<\/p>\n Wir müssen also noch zwei änderungen vornehmen. Die erste bezieht sich auf die Datenherkunft, die von nun an aus der folgenden Abfrage bestehen soll:<\/p>\n Dies führt dazu, dass nur noch solche Datensätze angezeigt werden, deren Feld GeloeschtAm <\/b>noch leer ist und die dementsprechend noch nicht gelöscht wurden. Übrigens sollten Sie die Felder mit den änderungsdaten dringend mit einem Index versehen, da sonst schnell die Performance in den Keller geht.<\/p>\n Das zweite Problem ist schwieriger zu lösen. Wie bringen wir dem Formular bei, seine Datenherkunft unabhängig vom Löschvorgang zu aktualisieren Hier hilft nur das gute, alte Timer<\/b>-Ereignis.<\/p>\n Dieses wird ja normalerweise in regelmäßigen zeitlichen Abständen, die über die Eigenschaft Zeitgeberintervall <\/b>festgelegt werden, ausgelöst. Hier soll dieses Ereignis nicht von Beginn an feuern, daher behalten Sie den Wert 0 <\/b>für die Eigenschaft Zeitgeberintervall <\/b>bei.<\/p>\n Die Eigenschaft soll erst geändert werden, wenn der Löschvorgang läuft. Daher stellen Sie diese innerhalb der Ereignisprozedur, die durch das Ereignis Nach Aktualisierung <\/b>ausgelöst wird, auf den Wert 100 <\/b>ein (entspricht einer zehntel Sekunde):<\/p>\n Aus der oben bereits beschriebenen Ereignisprozedur Beim Löschen <\/b>entfernen Sie die Zeile bolDelete = False<\/b>:<\/p>\n Schließlich definieren Sie noch eine Prozedur, die durch den Zeitgeber ausgelöst wird. Diese sieht wie folgt aus:<\/p>\n Die Routine stellt zunächst den Wert von TimerInterval <\/b>auf 0 <\/b>ein, damit die Routine nur einmal pro Löschvorgang ausgelöst wird. Dann prüft sie den Wert der Variablen bolDeleted<\/b>, der in der Routine Form_Delete <\/b>auf True <\/b>eingestellt wurde und die Durchführung eines Löschvorgangs anzeigt.<\/p>\n Hat diese den Wert True<\/b>, wird das Formular aktualisiert und schließlich die Variable bolDelete <\/b>auf False <\/b>eingestellt, damit die nächste änderung nicht ebenfalls als Löschung interpretiert wird.<\/p>\n Protokollieren von änderungen in SQL-Anweisungen<\/b><\/p>\n Nicht alle änderungen erfolgen zwangsläufig über Formulare, sondern auch über die (nicht so praktische) Methode DoCmd.RunSQL <\/b>und über die zu bevorzugende Execute<\/b>-Methode des Database<\/b>-Objekts. Diese Methoden dienen unter anderem dazu, Aktionsabfragen wie die Anfügeabfrage (INSERT INTO<\/b>), die Aktualisierungsabfrage (UPDATE<\/b>) und die Löschabfrage (DELETE<\/b>) durchzuführen.<\/p>\n Normalerweise können Sie sich hier nur einklinken, wenn Sie ein aktives Datenbankmanagementsystem wie MS SQL Server oder MySQL verwenden und die dort verfügbaren Trigger einsetzen (mehr zu diesem Thema im Beitrag Trigger<\/b>, Shortlink 636).<\/p>\n Wir bauen eine Lösung, die geringfügige änderungen am bestehenden Code erfordert, aber sonst sehr komfortabel ist.<\/p>\n Dazu definieren wir eine neue Klasse namens clsDB<\/b>. Diese enthält nur eine einzige Prozedur namens Execute<\/b>. In einem Standardmodul deklarieren Sie ein Objekt namens dba <\/b>wie folgt:<\/p>\n Das auf der Klasse clsDB <\/b>basierende Objekt ist wegen des New<\/b>-Schlüsselworts nun ständig verfügbar.<\/p>\n Die Klasse enthält zunächst nur eine einzige Methode namens Execute <\/b>(s. Listing 2). Diese hat die gleichen Parameter wie die herkömmliche Execute<\/b>-Methode des Database-Objekts und arbeitet auch so ähnlich.<\/p>\n Listing 2: Execute-Ersatz für das Durchführen von Aktionsabfragen inklusive Schreiben von änderungsinformationen<\/p>\n Betrachten wir zunächst, was Sie in bestehendem Code ändern müssen, damit ein Datensatz etwa beim ändern automatisch das änderungsdatum im Feld ZuletztGeaendertAm <\/b>erhält. Ein solcher Aufruf würde, wenn Sie den Verweis auf CurrentDB <\/b>in einer Variablen namens db <\/b>speichern, so aussehen:<\/p>\n Wenn Sie möchten, dass die Execute<\/b>-Methode aus der Klasse clsDB <\/b>zusätzlich zur änderung auch noch das änderungsdatum einträgt, verwenden Sie folgenden Aufruf – der minimale Unterschied ist fett hervorgehoben:<\/p>\n Sie sehen: Der Aufwand hält sich in Grenzen. Genau so sieht es übrigens auch bei DELETE<\/b>– und bei INSERT INTO<\/b>-Anweisungen aus.<\/p>\n Abfangen von INSERT INTO<\/b><\/p>\n Wie aber funktioniert die Execute<\/b>-Methode nun genau Betrachten wir zunächst den einfachsten Fall – die INSERT<\/b>-Methode. Sie ist deshalb so einfach, weil man einen neu hinzugefügten Datensatz daran erkennt, dass sein Feld AngelegtAm <\/b>noch keinen Wert enthält – zumindest, wenn man bis dahin immer darauf geachtet hat, dass ein solcher Wert eingetragen wird.<\/p>\n Die Execute<\/b>-Methode ermittelt zunächst den Typ der Aktionsabfrage, indem sie den Text bis zum ersten Leerzeichen ausliest und damit die Zweige eines Select Case<\/b>-Konstrukts ansteuert.<\/p>\n Der Codeabschnitt, der sich um diesen Abfragetyp kümmert, befindet sich im Select Case<\/b>-Zweig Case "INSERT"<\/b>. Dem INSERT INTO<\/b> einer solchen Aktionsabfrage folgt immer der Tabellenname und dann entweder eine SELECT<\/b>-Abfrage mit dem Quellausdruck oder eine öffnende Klammer gefolgt von den Zielfeldern:<\/p>\n Die Methode will nicht prüfen, ob eine SELECT<\/b>-Abfrage als Datenherkunft dient oder ob gezielt bestimmte Felder mit Daten gefüllt werden sollen – sie will einfach nur wissen, in welchem Bereich der SQL-Abfrage sich der Tabellenname befindet.<\/p>\n Also muss sie herausfinden, ob hinter INSERT INTO <\/b>zuerst ein SELECT <\/b>oder eine Klammer folgt, und die Position des ersten Zeichens des Siegers ermitteln. Mit dieser Zahl ermittelt die Routine dann leicht den Namen der Zieltabelle, der für die folgenden Schritte schon völlig ausreicht:<\/p>\n Abfangen von UPDATE<\/b><\/p>\n Bei der UPDATE<\/b>-Anweisung sieht das schon anders aus: Hier kann man nicht einfach die UPDATE-Anweisung ausführen und dann allen Datensätzen, die noch keinen Wert im Feld ZuletztGeaendertAm <\/b>aufweisen, die aktuelle Zeit zuweisen.<\/p>\n Hier ist die Vorgehensweise ein wenig diffiziler: Wir brauchen nämlich nicht nur die Zieltabelle, sondern auch noch die WHERE<\/b>-Bedingung und gegebenenfalls angegebene INNER JOIN<\/b>s und die entsprechenden Tabellen- und Feldnamen.<\/p>\n Der UPDATE<\/b>-Zweig der Select Case<\/b>-Bedingung identifiziert zwei Elemente der mit dem Parameter strQuery <\/b>übergebenen Abfrage: den Ausdruck mit der oder den Tabellen und die WHERE<\/b>-Klausel.<\/p>\n Aus der folgenden Anweisung würde die Routine also etwa die Ausdrücke tblKunden INNER JOIN tblProjekte ON tblKunden.KundeID = tblProjekte.KundeID <\/b>und WHERE Projekt = “lala“" <\/b>extrahieren:<\/p>\n Daraus baut die Routine eine neue Abfrage zusammen, die für das vorliegende Beispiel so aussieht:<\/p>\n Die Frage stimmt mit der vorherigen überein, aber sie ändert nicht das dort für die änderung vorgesehene Feld (dies könnten auch mehrere Felder sein), sondern das Feld ZuletztGeaendertAm<\/b>.<\/p>\n Beim Ausführen der beiden Abfragen spielt die Reihenfolge eine entscheidende Rolle: Zunächst müssen Sie nämlich das neue änderungsdatum eintragen und erst dann die eigentlichen änderungen durchführen. Der Grund ist einfach: Es könnte sonst passieren, dass die eigentliche Aktionsabfrage einen in der WHERE<\/b>-Klausel verwendeten Wert ändert, wodurch die Aktionsabfrage zum Eintragen des änderungsdatums den entsprechenden Datensatz nicht mehr findet.<\/p>\n Löschen ohne zu löschen<\/b><\/p>\n Richtig interessant wird es beim Löschen eines Datensatzes, wobei der Löschvorgang ja eigentlich gar keiner ist, sondern nur das Setzen eines Löschen-Flags (hier das Löschdatum) erledigt.<\/p>\n Nehmen wir eine einfache Löschabfrage als Beispiel:<\/p>\n Der Datensatz soll aber gar nicht gelöscht, sondern nur um einen Eintrag im Feld GeloeschtAm <\/b>erweitert werden. Die neue Execute<\/b>-Methode verwirft die als Parameter übergebene DELETE<\/b>-Anweisung komplett und erstellt stattdessen eine UPDATE<\/b>-Anweisung, die für dieses Beispiel so aussieht:<\/p>\n Übernommen wird hier nur der Name der betroffenen Tabelle und die WHERE<\/b>-Bedingung. Neben dem Setzen des Werts für das Feld GeloeschtAm <\/b>erledigt die Abfrage noch eine wichtige Aufgabe – sie fügt ein weiteres Element an die WHERE<\/b>-Klausel an, das sicherstellt, dass nur noch nicht gelöschte Datensätze berücksichtigt werden.<\/p>\n DAO: Edit, AddNew, Update und Delete<\/b><\/p>\n Nachdem wir die Datenänderungen in Formularen und mit der Execute<\/b>-Methode berücksichtigt haben, fehlen eigentlich noch die DAO-Methoden AddNew<\/b>, Edit<\/b>, Update <\/b>und Delete<\/b>. Es ist möglich, eine Klasse analog zur Klasse clsDB <\/b>zu erstellen, welche diese Funktionen kapselt. Der Aufwand wäre allerdings ungleich höher und würde den Rahmen dieses Beitrags sprengen.<\/p>\n Die Fälle, in denen Sie Daten nicht mit der Execute<\/b>-Anweisung ändern können, sondern die entsprechenden DAO-Methoden bemühen müssen, sind allerdings überschaubar. Sollten sich doch Vorkommen in Ihrem Code finden, ersetzen Sie diese entweder durch entsprechende Execute<\/b>-Methoden oder fügen die änderungsinformationen innerhalb von AddNew<\/b>\/Edit <\/b>und Update <\/b>hinzu beziehungsweise ersetzen die Delete<\/b>-Anweisung entsprechend (soweit ich weiß, sind solche Vorkommen aber äußerst selten).<\/p>\n Vorbereiten der Datenherkünfte auf gelöschte Datensätze<\/b><\/p>\n Ein sehr wichtiger Schritt bei der hier geschilderten Vorgehensweise ist die Anpassung der Datenherkünfte von Formularen, Berichten, Steuerelementen und auch innerhalb von VBA-Routinen für das Herausfiltern von als gelöscht markierten Datensätzen.<\/p>\n Diese verschwinden ja nicht mehr physisch aus dem Datenbestand, sondern enthalten im Gegensatz zu nicht gelöschten Datensätzen lediglich ein Datum in einem Feld namens GeloeschtAm<\/b>. <\/p>\n Sie müssen also die WHERE<\/b>-Klausel aller Datenherkünfte, die sich auf eine betroffene Tabelle beziehen, um den Ausdruck GeloeschtAm IS NULL <\/b>erweitern beziehungsweise überhaupt erst eine entsprechende WHERE<\/b>-Klausel anlegen.<\/p>\n Das ist natürlich mit sehr viel Suchaufwand verbunden – vor allem, wenn Sie eine umfangreiche Anwendung nachträglich um die hier vorgestellten Funktionen erweitern möchten.<\/p>\n Falls dieser Aufwand den Rahmen sprengen sollte, können Sie dies allerdings auch ganz einfach erledigen – allerdings auf Kosten einiger neuer Datenbankobjekte: Dazu benennen Sie einfach die Originaltabellen um, indem Sie ihnen einen Unterstrich (_<\/b>) hinzufügen, eine 1 <\/b>anhängen oder irgendeine andere mehr oder weniger sinnvolle änderung vornehmen.<\/p>\n Aber Achtung: Vergessen Sie nicht, die Objektnamen-Autokorrektur zuvor abzuschalten, sonst ist der gewünschte Effekt dahin – Access würde dann die Referenzen auf die betroffenen Elemente gleich mit ändern, soweit möglich.<\/p>\n Natürlich funktioniert danach nicht mehr viel, denn Formulare, Berichte oder Steuerelemente und auch die im VBA-Code enthaltenen Abfragen finden die Tabellen nun einfach nicht mehr.<\/p>\n Aber jetzt kommt der Clou: Erstellen Sie einfach für jede betroffene Tabelle eine Abfrage, die alle Felder der jeweiligen Tabelle enthält (einfach alle Felder markieren und in das Entwurfsraster ziehen) und genauso heißt wie die alte Tabelle. Den feinen Unterschied macht das Feld GeloeschtAm<\/b>, dem Sie das Kriterium IS NULL <\/b>zuweisen.<\/p>\n Wenn ein Objekt nun nach tblKunden <\/b>sucht, findet es die Abfrage tblKunden<\/b>, die wiederum alle Daten der Tabelle tblKunden1<\/b> (ehemals tblKunden<\/b>) liefert. Je nach Umfang der Datenbank spart dies Unmengen Zeit, denn Sie brauchen so keine einzige Datenherkunft anzupassen.<\/p>\n Zusammenfassung und Ausblick<\/b><\/p>\n änderungsinformationen speichern können Sie auch ohne umfangreiche änderungen an der Datenbank.<\/p>\n Mit der hier vorgestellten Methode können Sie die meisten Fälle mit minimalem Aufwand abfangen: Die notwendigen Felder legen Sie mit einem einfachen Funktionsaufruf an, das ändern gebundener Daten in Formularen erledigen Sie durch das Hinzufügen zweier kleiner Ereignisprozeduren und auch für die Execute<\/b>-Methode des Database<\/b>-Objekts haben wir einen schönen Workaround gefunden, bei dem Sie auch noch ganz normal die DELETE<\/b>-Anweisung weiterverwenden können, ohne dass diese tatsächlich Daten löscht. Und mit dem Trick zum Herausfiltern der als gelöscht markierten Datensätze ist auch die letzte Hürde schnell genommen.<\/p>\n Enthaltene Beispieldateien:<\/p>\n Aenderungshistorie.mdb<\/p>\nALTER TABLE tblKunden\r\nADD AngelegtAm DATETIME<\/pre>\n
ALTER TABLE tblKunden ADD AngelegtDurch INTEGER\r\nALTER TABLE tblKunden ADD CONSTRAINT\r\nFKAngelegtDurch FOREIGN KEY (AngelegtDurch)\r\nREFERENCES tblKunden<\/pre>\n
Public Function AddHistoryFieldsToTable(strTableChange As String, strTableUsers As String)\r\n ''AngelegtAm und AngelegtDurch\r\n dbs.Execute "ALTER TABLE " & strTableChange & " ADD AngelegtAm DATETIME", dbFailOnError\r\n dbs.Execute "ALTER TABLE " & strTableChange & " ADD AngelegtDurch INTEGER", dbFailOnError\r\n dbs.Execute "ALTER TABLE " & strTableChange & " ADD CONSTRAINT FKAngelegtDurch " _\r\n & "FOREIGN KEY (AngelegtDurch) REFERENCES " & strTableUsers, dbFailOnError\r\n ''ZuletztGeaendertAm und ZuletztGeaendertDurch\r\n dbs.Execute "ALTER TABLE " & strTableChange & " ADD ZuletztGeaendertAm DATETIME", dbFailOnError\r\n dbs.Execute "ALTER TABLE " & strTableChange & " ADD ZuletztGeaendertDurch INTEGER", dbFailOnError\r\n dbs.Execute "ALTER TABLE " & strTableChange & " ADD CONSTRAINT FKGeaendertDurch " _\r\n & "FOREIGN KEY (GeaendertDurch) REFERENCES " & strTableUsers, dbFailOnError\r\n ''GeloeschtAm und GeloeschtDurch\r\n dbs.Execute "ALTER TABLE " & strTableChange & " ADD GeloeschtAm DATETIME", dbFailOnError\r\n dbs.Execute "ALTER TABLE " & strTableChange & " ADD GeloeschtDurch INTEGER", dbFailOnError\r\n dbs.Execute "ALTER TABLE " & strTableChange & " ADD CONSTRAINT FKGeloeschtDurch " _\r\n & "FOREIGN KEY (GeloeschtDurch) REFERENCES " & strTableUsers, dbFailOnError\r\nEnd Function\r\nAddHistoryFieldsToTable "tblKunden", "tblBenutzer"<\/pre>\n
![\"pic002.png\"](\"..\/fileadmin\/_temp_\/2009_04\/Aenderungshistorie-web-images\/pic002_opt.jpeg\")
<\/p>\n![\"pic003.png\"](\"..\/fileadmin\/_temp_\/2009_04\/Aenderungshistorie-web-images\/pic003_opt.jpeg\")
<\/p>\nPrivate Sub Form_BeforeUpdate(Cancel As Integer)\r\n If Me.NewRecord = True Then\r\n Me!AngelegtAm = Now\r\n Else\r\n Me!ZuletztGeaendertAm = Now\r\n End If\r\n End Sub<\/pre>\n
Private Sub Form_Delete(Cancel As Integer)\r\n Me!GeloeschtAm = Now\r\n Me.Dirty = False\r\n Cancel = True\r\n End Sub<\/pre>\n
Dim bolDelete As Boolean<\/pre>\n
Private Sub Form_Delete(Cancel As Integer)\r\n Me!GeloeschtAm = Now\r\n bolDelete = True\r\n Me.Dirty = False\r\n bolDelete = False\r\n Cancel = True\r\n End Sub<\/pre>\n
Private Sub Form_BeforeUpdate(Cancel As Integer)\r\n If Me.NewRecord = True Then\r\n Me!AngelegtAm = Now\r\n Else\r\n If bolDelete = False Then\r\n Me!ZuletztGeaendertAm = Now\r\n End If\r\n End If\r\n End Sub<\/pre>\n
SELECT * FROM tblKunden WHERE GeloeschtAm IS NULL<\/pre>\n
Private Sub Form_AfterUpdate()\r\n Me.TimerInterval = 100\r\n End Sub<\/pre>\n
Private Sub Form_Delete(Cancel As Integer)\r\n Me!GeloeschtAm = Now\r\n bolDelete = True\r\n Me.Dirty = False\r\n Cancel = True\r\n End Sub<\/pre>\n
Private Sub Form_Timer()\r\n Me.TimerInterval = 0\r\n If bolDelete Then\r\n Me.Requery\r\n Me.Recordset.MoveLast\r\n End If\r\n bolDelete = False\r\n End Sub<\/pre>\n
Public dba As New clsDB<\/pre>\n
Public Sub Execute(strQuery As String, Optional lngOptions As Long)\r\n...\r\nintPosStart = InStr(1, strQuery, " ")\r\nstrAction = Trim(Left(strQuery, intPosStart))\r\nSelect Case strAction\r\nCase "INSERT"\r\nintPosStart = Len("INSERT INTO ")\r\nintPosEnde = InStr(intPosStart, strQuery, "(")\r\nintPosEndeTemp = InStr(intPosStart, strQuery, " SELECT ")\r\nIf intPosEnde < intPosEndeTemp And intPosEnde = 0 Then intPosEnde = intPosEndeTemp\r\nstrAction = "INSERT INTO"\r\nstrTable = Trim(Mid(strQuery, intPosStart, intPosEnde - intPosStart))\r\ndbs.Execute strQuery, lngOptions\r\nstrSQLHistory = "UPDATE " & strTable & " SET AngelegtAm = " & ISODatum(Now) _\r\n& " WHERE AngelegtAm IS NULL"\r\ndbs.Execute strSQLHistory, dbFailOnError\r\nCase "UPDATE"\r\nintPosStart = Len("UPDATE ")\r\nintPosEnde = InStr(intPosStart, strQuery, "SET")\r\nstrAction = "UPDATE"\r\nstrTable = Trim(Mid(strQuery, intPosStart, intPosEnde - intPosStart))\r\nintPosStart = InStr(1, strQuery, " WHERE ")\r\nintPosEnde = Len(strQuery)\r\nstrWHERE = Mid(strQuery, intPosStart, intPosEnde - intPosStart + 1)\r\nstrSQLHistory = "UPDATE " & strTable & " SET ZuletztGeaendertAm = " & ISODatum(Now) _\r\n& strWHERE\r\ndbs.Execute strSQLHistory, dbFailOnError\r\ndbs.Execute strQuery, lngOptions\r\nCase "DELETE"\r\nintPosStart = InStr(1, strQuery, " FROM ") + 6\r\nintPosEnde = InStr(intPosStart, strQuery, " WHERE ")\r\nIf intPosEnde = 0 Then\r\n intPosEnde = Len(strQuery)\r\nEnd If\r\nstrAction = "DELETE"\r\nstrTable = Trim(Mid(strQuery, intPosStart, intPosEnde - intPosStart + 1))\r\nintPosStart = InStr(1, strQuery, " WHERE ")\r\nIf intPosStart > 0 Then\r\n intPosEnde = Len(strQuery)\r\n strWHERE = Mid(strQuery, intPosStart, intPosEnde - intPosStart + 1)\r\nEnd If\r\nIf Len(strWHERE) = 0 Then\r\n strWHERE = " WHERE "\r\nElse\r\n strWHERE = strWHERE & " AND "\r\nEnd If\r\nstrWHERE = strWHERE & "GeloeschtAm IS NULL"\r\nstrSQLHistory = "UPDATE " & strTable & " SET GeloeschtAm = " & ISODatum(Now) & strWHERE\r\ndbs.Execute strSQLHistory, dbFailOnError\r\nEnd Select\r\nEnd Sub<\/pre>\ndb.Execute "UPDATE tblKunden SET Kundenname = ''Müller'' WHERE Kundenname = ''Mueller''"<\/pre>\n
dba<\/b>.Execute "UPDATE tblKunden SET Kundenname = ''Müller'' WHERE Kundenname = ''Mueller''"<\/pre>\n
INSERT INTO tblKunden SELECT ...\r\nINSERT INTO tblKunden(Kundenname ...<\/pre>\n
\n
UPDATE tblKunden INNER JOIN tblProjekte\r\nON tblKunden.KundeID = tblProjekte.KundeID\r\nSET Kundenname = ''Kurt'' WHERE Projekt = ''lala''"<\/pre>\n
UPDATE tblKunden INNER JOIN tblProjekte\r\nON tblKunden.KundeID = tblProjekte.KundeID\r\nSET ZuletztGeaendertAm = #2009\/05\/12 20:49:55#\r\nWHERE Projekt = ''lala''<\/pre>\n
DELETE FROM tblKunden\r\nWHERE Kundenname = ''Minhorst''<\/pre>\n
UPDATE tblKunden SET GeloeschtAm = #2009\/05\/12 20:55:38# WHERE Kundenname = ''Minhorst'' AND GeloeschtAm IS NULL<\/pre>\n
Downloads zu diesem Beitrag<\/h3>\n