<\/p>\n
Seit Jahren wünscht die Access-Entwicklergemeinde sich Trigger. Damit legt man gleich im Tabellenentwurf fest, was geschieht, wenn ein Benutzer Datensätze anlegt, bearbeitet oder löscht. Doch diese nützlichen Helferlein blieben den Entwicklern von Systemen wie SQL Server, MySQL und Co. vorbehalten. Mit Access 2010 tut sich jedoch etwas in diesem Bereich: Mit den Datenmakros will Microsoft Trigger auch für Access verfügbar machen. Wir schauen uns an, was dabei herausgekommen ist.<\/b><\/p>\n
Sinn und Zweck von Datenmakros<\/b><\/p>\n
Genau wie Trigger in anderen Datenbankmanagementsystemen sollen Datenmakros ausgelöst werden, wenn der Benutzer eine der folgenden Aktionen durchführt:<\/p>\n
Nun wissen wir zwar, wann Datenmakros ausgelöst werden, aber wofür kann man diese Objekte denn nun gebrauchen Der einfachste Anwendungsfall ist wohl das Protokollieren von änderungen an den Daten einer Tabelle. Sicher kennen Sie Varianten von Tabellen, die Felder wie ErstelltAm<\/b>, ErstelltDurch<\/b>, GeaendertAm<\/b>, GeaendertDurch<\/b>, GeloeschtAm <\/b>und GeloeschtDurch <\/b>enthalten.<\/p>\n
Deren Inhalte können natürlich nur dann automatisch geändert werden, wenn die änderungen selbst ein entsprechendes Ereignis auslösen. Bislang hat man sich dabei damit beholfen, dass man davon ausging, dass Benutzer die Daten einer Tabelle nur über ein Formular ändern und niemals direkt auf die Tabelle zugreifen.<\/p>\n
In Formularen gibt es schließlich Ereigniseigenschaften, welche entsprechende Prozeduren auslösen können. Dort bringt man dann Code unter, der dafür sorgt, dass die Felder zur änderungsprotokollierung auf dem aktuellsten Stand gehalten werden.<\/p>\n
Das Problem dabei ist nur, dass es sehr viele Möglichkeiten gibt, den Inhalt einer Tabelle zu ändern. Der Benutzer kann dies direkt über ein an die Tabelle gebundenes Formular erledigen oder ein Ereignis kann Code zum Aktualisieren der Tabelle via DAO, ADODB oder direkt per SQL-Anweisung auslösen.<\/p>\n
Schließlich gibt es auch noch Aktionsabfragen, die Datensätze anlegen, ändern oder löschen können. Dies alles macht deutlich, dass der Entwickler an einer ganzen Reihe von Stellen dafür sorgen muss, dass änderungen auch wirklich protokolliert werden.<\/p>\n
Wenn Sie die Tabellen beispielsweise in einer SQL Server- oder MySQL-Datenbank speichern, ist dies viel einfacher: Sie können dort Trigger anlegen, die bei jeder Datenänderung ausgelöst werden. Für jeden Trigger definieren Sie, was dieser erledigen soll – in diesem Fall die änderungsinformationen in die Tabelle eintragen.<\/p>\n
Nun aber sollen die sogenannten Datenmakros die Aufgabe der Trigger auch in Access-Tabellen übernehmen. Schauen wir uns also an, wie dies funktioniert.<\/p>\n
Datenmakros verwalten<\/p>\n
Die Datenmakros von Access 2010 bearbeiten Sie in der Entwurfsansicht der jeweiligen Tabelle. Die notwendigen Befehle finden Sie im Ribbon-Bereich Entwurf|Feld-, Datensatz- und Tabellenereignisse<\/b>. Dort lassen sich Datenmakros erstellen sowie löschen oder umbenennen (s. Bild 1).<\/p>\n
![\"pic001.png\"](\"..\/fileadmin\/_temp_\/2011_01\/Datenmakros-web-images\/pic001.png\")
<\/p>\n
Bild 1: Datenmakros legen Sie in der Entwurfsansicht einer Tabelle an.<\/span><\/b><\/p>\n Wir wollen zunächst für alle möglichen Aktionen ein Datenmakro anlegen, das einfach nur mitteilt, durch welche Aktion es jeweils ausgelöst wurde. Für das Datenmakro Nach Einfügung <\/b>soll so beispielsweise ein Meldungsfenster erscheinen, das uns informiert, dass soeben ein Datensatz eingefügt wurde. ähnliche Datenmakros legen wir für alle fünf verfügbaren Datenaktionen an.<\/p>\n Definition von Datenmakros<\/b><\/p>\n Datenmakros haben genau die gleiche Syntax wie herkömmliche Makros. Diese wurden unter Access 2010 deutlich überarbeitet. Die Neuerungen bezüglich dieses Objekttyps finden Sie im Detail im Beitrag Makros in Access 2010 <\/b>(www.access-im-unternehmen.de\/759<\/b>).<\/p>\n Trotz der gleichen Syntax verwenden Datenmakros nur ganz wenige der in herkömmlichen Makros vorkommenden Aktionen. Dafür gibt es eine ganze Reihe spezieller Aktionen wie AuslösenFehler<\/b>, DatensatzBearbeiten <\/b>oder ProtokollierenEreignis<\/b> (s. Bild 2).<\/p>\n Bild 2: Für Datenmakros stehen andere Aktionen zur Verfügung als für normale Makros.<\/span><\/b><\/p>\n Unser Plan, beim Anlegen eines Datensatzes eine Meldung auszugeben, fällt somit ins Wasser: Das Ausgeben von Meldungen ist in Datenmakros nicht vorgesehen. Dafür gibt es eine Aktion namens ProtokollierenEreignis <\/b>– mal sehen, was wir damit anstellen können. Wir legen also ein erstes Datenmakro an, das beim Anlegen eines Datensatzes in der Tabelle tblKunden<\/b> ein Ereignis protokolliert.<\/p>\n Dort tragen wir den folgenden Ausdruck ein (s. Bild 3):<\/p>\n Bild 3: Dieser Ausdruck soll beim Anlegen eines neuen Datensatzes protokolliert werden.<\/span><\/b><\/p>\n Nach dem Wechsel in die Datenblattansicht und dem Anlegen eines neuen Datensatzes geschieht nichts. Der Datensatz wird wie gewohnt angelegt, aber wenn dies protokolliert wird, erfolgt dies in aller Heimlichkeit. Das ist aber auch gut so: Wer will schon beim Anlegen, ändern oder Löschen eines Datensatzes immer darauf hingewiesen werden, was er soeben getan hat. <\/p>\n Wenn man sich nicht drum kümmert, stößt man vielleicht beim nächsten Besuch des Datei<\/b>-Tabs auf die neue Schaltfläche Anwendungsprotokolltabelle anzeigen <\/b>(s. Bild 4).<\/p>\n Bild 4: Das Anwendungsprotokoll lassen Sie sich über diesen Menüpunkt im Backstage-Bereich anzeigen.<\/span><\/b><\/p>\n Ein Klick auf diese Schaltfläche öffnet die Tabelle USysApplicationLog<\/b> – eine Art Systemtabelle, die beim ersten Protokollieren eines Datenmakros angelegt wird und im Datenbankfenster nur angezeigt wird, wenn die Option Systemtabellen anzeigen <\/b>aktiviert ist.Im Gegensatz zu den übrigen Systemtabellen können Sie aber die enthaltenen Daten ändern und sogar die komplette Tabelle löschen, wenn Sie die gespeicherten Daten nicht mehr benötigen.<\/p>\n Diese Tabelle zeigt beispielsweise an, welches Objekt den Eintrag verursacht hat (hier das AfterInsert<\/b>-Datenmakro der Tabelle tblKunden<\/b>), ob es einen Fehler gab und wann der Eintrag stattfand. Außerdem finden wir unseren Protokolltext wieder, und zwar im Feld Description<\/b>.<\/p>\n Wenn ein Datenmakro einen Fehler auslöst, wird dieser übrigens auch in dieser Tabelle gespeichert; in diesem Fall landet der Fehlertext im Feld Description<\/b> (s. Bild 5).<\/p>\n Bild 5: Diese Tabelle speichert bei der Durchführung von Datenmakros anfallende Meldungen.<\/span><\/b><\/p>\n Makros in der Datenblattansicht ändern<\/b><\/p>\n Wenn Sie die Option Aktuelle Datenbank|Anwendungsoptionen|Entwurfsänderungen für Tabellen in der Datenblattansicht aktivieren <\/b>eingeschaltet haben, können Sie Datenmakros sogar in der Datenblattansicht von Tabellen ändern.<\/p>\n Auch wenn wir normalerweise gegen das ändern des Tabellenentwurfs in der Datenblattansicht sind, spart das Bearbeiten der Datenmakros in dieser Ansicht doch das lästige Hin- und Herschalten zwischen Entwurf und Datenblatt.<\/p>\n Sie finden die entsprechenden Schaltflächen zum Anlegen beziehungsweise Bearbeiten der Datenmakros im Ribbon-Tab Tabelle <\/b>(s. Bild 6).<\/p>\n Bild 6: Wenn bereits ein Datenmakro für eine Tabelle hinterlegt ist, wird die Schaltfläche zum Aufrufen dieses Makros farblich hervorgehoben.<\/span><\/b><\/p>\n Dort werden bereits vorhandene Datenmakros übrigens farbig hervorgehoben.<\/p>\n Die Aktionen der Datenmakros<\/b><\/p>\n Werfen wir nun einen Blick auf die verschiedenen Aktionen der Datenmakros. Die Aktion ProtokollierenEreignis <\/b>haben wir ja bereits ansatzweise kennengelernt. Interessant sind hier noch die verschiedenen Parameter.<\/p>\n Wenn Sie wie in Bild 7 die Liste der möglichen Elemente mit der Tastenkombination Strg + Leertaste <\/b>aufklappen, finden Sie beispielsweise sämtliche Feldnamen der aktuellen Tabelle, aber auch die VBA-Funktionen in der jeweiligen Landessprache vor. Zusätzlich gibt es ein paar datenmakro-spezifische Elemente, von denen zunächst die folgenden beiden interessant sind:<\/p>\n Bild 7: Über die Feldnamen greifen Sie auf die Werte des aktuellen Datensatzes zu.<\/span><\/b><\/p>\n Datenblöcke<\/b><\/p>\n Neben diesen Elementen gibt es einige sogenannte Datenblöcke. Diese repräsentieren einige Standardabläufe, die normalerweise mit DAO oder ADODB programmiert werden. Die vier Datenblöcke lauten (englische Bezeichnungen in Klammern, falls Sie mit der englischen Version von Access arbeiten sollten):<\/p>\n Datenaktionen<\/b><\/p>\n Den größten Teil der Elemente machen die Datenaktionen aus. Einige von ihnen können immer ausgeführt werden, andere nur in bestimmten Zusammenhängen:<\/p>\n <\/p>\n Beispielanwendung: änderungshistorie<\/b><\/p>\n Für die Beispielanwendung erweitern wir die Tabelle tblKunden <\/b>um die drei Felder AngelegtAm<\/b>, GeaendertAm <\/b>und GeloeschtAm<\/b>. Je nach änderung soll hier das entsprechende Datum eingetragen werden.<\/p>\n Beginnen wir gleich mit dem Anlegen eines neuen Datensatzes. Dies erledigt das Makro aus Bild 8.<\/p>\n Bild 8: Dieses Makro fügt einem neuen Datensatz das Anlegedatum hinzu.<\/span><\/b><\/p>\n Die erste Aktion dient lediglich demonstrativen Zwecken: Sie schreibt einen Kommentar mit der ID des neuen Datensatzes in die Systemtabelle USysApplicationLog<\/b>.<\/p>\n Danach geht es richtig los: Wir erstellen zunächst eine Referenz auf den neu angelegten Datensatz. Dazu verwenden wir die Aktion NachschlagenDatensatz <\/b>und verwenden als Bedingung den Ausdruck [tblKunden].[KundeID] = [KundeID]<\/b>.<\/p>\n Wir haben nun im Prinzip eine Datensatzgruppe erzeugt, die genau den neu angelegten Datensatz enthält. Sie könnten dieser Datensatzgruppe nun noch einen Namen geben, indem Sie den Parameter Alias <\/b>mit einem Wert wie rstNeu <\/b>füllen. Da wir aber hier nur mit einem einzigen Datensatz arbeiten, ist dies nicht nötig. Damit die folgende DatensatzBearbeiten<\/b>-Aktion jedoch weiß, dass sie sich auf den soeben ermittelten Datensatz beziehen soll, legen wir die DatensatzBearbeiten<\/b>-Aktion in der Hierarchie unterhalb der NachschlagenDatensatz<\/b>-Aktion an. Im Screenshot erkennen Sie dies durch die leichte Einrückung.<\/p>\n Der Grund ist, dass Access sich den gefundenen Datensatz so lange merkt, bis Sie die Struktur verlassen, in der Sie den Datensatz ermittelt haben.<\/p>\n Sie können also so lange immer wieder auf die Felder des Datensatzes zugreifen und ihre Werte ändern, bis die nächste änderung auf der gleichen Ebene von NachschlagenDatensatz <\/b>ausgelöst wird (der graue Hintergrund in Bild 8 verdeutlicht dies).<\/p>\n Warum nicht einfacher<\/b><\/p>\n Die Vorgehensweise könnte man sich einfacher vorstellen. Access ermöglicht, wie wir gesehen haben, gleich nach dem Anlegen des neuen Datensatzes Zugriff auf seine Felder.<\/p>\n So konnten wir gleich den Datensatz referenzieren, der den Primärschlüsselwert des neu angelegten Datensatzes besitzt, und den Wert des Feldes AngelegtAm <\/b>füllen.<\/p>\n Wenn wir den neuen Primärschlüsselwert gleich nach dem Anlegen lesen können, haben wir doch offensichtlich Zugriff auf den neuen Datensatz – warum also können wir das Feld AngelegtAm <\/b>nicht gleich füllen Die Antwort ist einfach: Alle Datenmakros stellen einen Datensatz mit dem aktuellen Stand bereit, aber dieser ist schlicht schreibgeschützt.<\/p>\n Datensatzänderungen speichern<\/b><\/p>\n Bei änderungen am Datensatz sieht es ganz ähnlich aus. Wenn wir beim ändern mindestens eines Feldes eines Datensatzes das änderungsdatum in ein Feld namens GeaendertAm <\/b>eintragen möchten, verwenden wir das Datenmakro Nach Aktualisierung<\/b>.<\/p>\n Dieses füllen wir wie in Bild 9. Das Makro ist genau so wie das für das Anlegen aufgebaut – es wird lediglich ein anderes Feld geändert.<\/p>\n Bild 9: Dieses Makro trägt das änderungsdatum eines Datensatzes ein.<\/span><\/b><\/p>\n Wenn Sie einen Datensatz ändern, wird dieses Makro die erwünschte Wirkung erzielen.<\/p>\n Was aber, wenn Sie einen neuen Datensatz anlegen Logischerweise löst auch das Anlegen eines Datensatzes gleich das Datenmakro Nach Aktualisierung <\/b>mit aus.<\/p>\n Das heißt, dass beim Anlegen eines Datensatzes nicht nur das Feld AngelegtAm<\/b>, sondern auch GeaendertAm <\/b>mit dem aktuellen Datum gefüllt wird.<\/p>\n Ist das ein Problem Nein, eigentlich nicht, denn letztlich entspricht das Anlegen eines Datensatzes ja dem ändern mindestens eines seiner Felder. Wir belassen dieses Verhalten also wie gehabt.<\/p>\n Detaillierte änderungshistorie<\/p>\n Vielleicht möchten Sie nicht nur festhalten, wann ein Datensatz geändert wurde, sondern welche änderungen genau erfolgt sind. In diesem Fall müssen wir das Datenmakro, das beim ändern ausgelöst wird, etwas erweitern.<\/p>\n Zusätzlich benötigen wir eine weitere Tabelle, die folgende Daten speichert:<\/p>\n Den Benutzer, der die änderung durchführt, lassen wir weiterhin außen vor. Die Tabelle zum Speichern der geänderten Daten sieht wie in Bild 10 aus.<\/p>\n Bild 10: Diese Tabelle speichert die änderungshistorie.<\/span><\/b><\/p>\n Das Makro schließlich wird etwas umfangreicher als die bisherigen Makros. Der Grund ist, dass wir die änderungen jedes einzelnen Feldes separat prüfen möchten. Wir wissen ja nicht, welches der Felder des Datensatzes geändert wurde und somit das Datenmakro ausgelöst hat – es kann ein einziges Feld sein, der Benutzer kann aber auch mehrere Felder geändert haben.<\/p>\n Da wir aber ohnehin die änderungen an jedem einzelnen Feld speichern möchten, müssen wir auch alle Felder prüfen. Das Makro aus Bild 11 beginnt mit einer Wenn<\/b>-Bedingung, die prüft, ob der alte Inhalt des Feldes Kunde <\/b>mit dem neuen übereinstimmt.<\/p>\n Bild 11: Speichern der änderungen im Feld Kunde der Tabelle tblKunden<\/span><\/b><\/p>\n Den Inhalt des alten Feldes erhalten wir über ein spezielles Tabellen-Alias, nämlich Alt <\/b>(in englischen Versionen: Old<\/b>). Den Wert des Feldes Kunden <\/b>in der neuen Version des Datensatzes können wir direkt über den Feldnamen abgreifen – ohne eine Tabelle oder ein Alias angeben zu müssen (dazu später mehr).<\/p>\n Wir könnten also mit der Bedingung Wenn Nicht ([Alt].[Kunde]=[Kunde]) Dann <\/b>prüfen, ob der Feldwert sich geändert hat.<\/p>\n Access bietet aber speziell für diesen Fall eine eigene Funktion an, nämlich Aktualisiert(<Feldname>)<\/b>. Diese macht das Zusammenstellen der Wenn-Bedingung natürlich noch einfacher. <\/p>\n Wurde der Name des Kunden geändert, werden die nachfolgenden Aktionen ausgeführt. Diese sind wiederum verschachtelt: Die äußere Aktion legt einen neuen Datensatz in der Tabelle tblAenderungshistorie <\/b>an (dies entspricht dem Erzeugen einer Datensatzgruppe und dem Anlegen eines neuen Datensatzes mit AddNew <\/b>unter DAO oder ADODB).<\/p>\n Darin verschachtelt befinden sich einige Aktionen, welche die einzelnen Felder dieses neuen Datensatzes füllen. Wichtig ist dabei, dass Sie die Anführungszeichen an den richtigen Stellen setzen:<\/p>\n Die Angabe von "tblKunden" <\/b>für das Feld GeaenderteTabelle <\/b>trägt tatsächlich diesen Ausdruck dort ein, während tblKunden <\/b>ohne Anführungszeichen zu einem Fehler führt: Access versucht dann auf ein Feld namens tblKunden <\/b>zuzugreifen, was aber nicht gelingt.<\/p>\n Wichtig ist auch, dass Sie beim Hinzufügen des neuen Wertes des Felds Kunde <\/b>nicht mehr ohne Angabe des Tabellennamens oder Alias auf dieses Feld des neu angelegten Datensatzes der Tabelle tblKunden <\/b>zugreifen können, sondern das Präfix tblKunden <\/b>voranstellen müssen – mehr dazu im folgenden Abschnitt.<\/p>\n Um das vorliegende Makro zu testen, ändern Sie einen bestehenden Datensatz und tragen dort einen neuen Wert für das Feld Kunde <\/b>ein. Anschließend finden Sie in der Tabelle tblAenderungshistorie <\/b>einen entsprechenden neuen Datensatz vor.<\/p>\n Greifbare Daten<\/b><\/p>\n Die ersten beiden Beispiele zeigen sehr schön, wie wir auf die Felder der einzelnen Tabellen zugreifen können. Allerdings sind dabei auch einige Punkte aufgetaucht, die genauer untersucht werden müssen.<\/p>\n Wenn Sie auf einen Wert eines neu angelegten oder geänderten Datensatzes zugreifen möchten, gelingt dies durch einfache Angabe des Feldnamens ohne führenden Tabellennamen. Beim ändern eines Datensatzes greifen Sie durch Voranstellen von Alt <\/b>beziehungsweise Old <\/b>auf die alten Feldwerte zu, also beispielsweise Alt.Kunde<\/b>.<\/p>\n Andererseits lassen sich von einem Datenmakro aus keine änderungen an einem Feld durchführen, indem Sie es einfach per Feldname referenzieren – es ist schlicht schreibgeschützt.<\/p>\n Wenn Sie dann mit der NachschlagenDatensatz<\/b>-Aktion auf diesen Datensatz zugreifen, können Sie wiederum nicht mehr direkt auf Feldnamen wie [Kunde] <\/b>zugreifen – Sie müssen den Tabellennamen voranstellen ([tblKunden.Kunde]<\/b>).<\/p>\n Dies gilt für alle Aktionen, mit denen Sie einen neuen Datensatz referenzieren – ob mit DatensatzBearbeiten<\/b>, DatensatzErstellen<\/b>, FürJedenDatensatz <\/b>oder NachschlagenDatensatz<\/b>. Der Kontext liegt nun auf dem neuen Datensatz und Sie können nun nicht mehr ohne Angabe eines Tabellennamens oder eines Alias auf die Felder einer Tabelle zugreifen.<\/p>\n Benannte Makros<\/p>\n Benannte Makros sind etwa mit Prozeduren oder Funktionen unter VBA vergleichbar. Sie können für benannte Makros Parameter festlegen und beim Aufruf entsprechende Werte übergeben, die im benannten Makro weiterverarbeitet werden können. <\/p>\n Die änderungshistorie ist ein prima Beispiel für solche benannten Makros, da wir prinzipiell für alle Felder der Tabelle prüfen müssen, ob der Feldinhalt im Vergleich zum vorherigen Stand geändert wurde, und dementsprechend einen Eintrag in die Tabelle tblAenderungshistorie<\/b> vornehmen müssen. <\/p>\n Wir können nun also ein benanntes Makro erstellen, das für uns prüft, ob der alte Wert dem neuen entspricht und gegebenenfalls die änderung dokumentiert.<\/p>\n Bild 12 zeigt das benannte Makro mit seinen Parametern. Benannte Makros können wie die Datenmakros nur in Zusammenhang mit einer Tabelle erstellen, es gibt keine globalen benannten Makros, die Sie von verschiedenen Tabellen aus aufrufen können.<\/p>\n Bild 12: Ein benanntes Makro, das von anderen Datenmakros aus aufgerufen werden kann.<\/span><\/b><\/p>\n Das Makro aus Bild 13 besitzt fünf Parameter, für die wir im Makro lediglich den Namen und, falls gewünscht, eine Beschreibung hinterlegen können. Auf die Parameter können wir in den folgenden Aktionen direkt zugreifen.<\/p>\n Bild 13: Benanntes Makro mit seinen Parametern<\/span><\/b><\/p>\n Der Aufruf eines solchen Makros erfolgt über die Aktion AusführenDatenmakro<\/b>. Nach der Auswahl des benannten Makros, das bereits vorliegen muss, blendet Access die Parameter dieses Makros ein. Hier tragen Sie nun die Werte ein, die an das Makro übergeben werden sollen.<\/p>\n Bild 14: Aufruf eines benannten Makros mit seinen Parametern<\/span><\/b><\/p>\n Zusammen führen Datenmakro und benanntes Makro nun die Funktion durch, die zuvor allein im Datenmakro aus Bild 11 untergebracht war. Nun brauchen Sie zum Speichern der änderungen nur noch für jedes Feld einmal den Aufruf des benannten Makros zu kopieren und einzufügen und anschließend die Parameter im Aufruf entsprechend dem zu prüfenden Feld anzupassen.<\/p>\n Achtung, Rekursion!<\/b><\/p>\n Wenn Sie dem Datenmakro Nach Aktualisierung <\/b>Aktionen zuweisen, die den Inhalt der geänderten Tabelle selbst ändern (beispielsweise durch das Eintragen eines änderungsdatums), geraten Sie in eine Endlos-Schleife: Durch das erneute ändern des Datensatzes wird das Datenmakro Nach Aktualisierung <\/b>erneut ausgelöst, schreibt wieder das änderungsdatum in das entsprechende Feld und so weiter.<\/p>\n Irgendwann erkennt Access dies, bricht die Operation ab und trägt eine entsprechende Meldung in die Tabelle USysApplicationLog <\/b>ein.<\/p>\n Wir möchten das Datenmakro zum Eintragen der änderungshistorie nun um einen Befehl erweitern, der den Zeitpunkt der letzten änderung in das Feld GeaendertAm <\/b>der Tabelle tblKunden <\/b>selbst einträgt.<\/p>\n Diese Aktion geschieht im Anschluss an die verschiedenen Aufrufe des benannten Makros zum Speichern der änderungen der einzelnen Felder in der Tabelle tblAenderungshistorie<\/b>. Die Vorgehensweise entspricht genau der beim Eintragen des Anlegedatums eines Datensatzes. <\/p>\n Viel interessanter ist es, die drohende Rekursion zu verhindern, denn durch das Eintragen des änderungsdatums wird ja wiederum das Datenmakro Nach Aktualisierung <\/b>ausgelöst.<\/p>\n Wir müssen also gleich zu Beginn des Makros prüfen, ob sich der Inhalt des Feldes GeaendertAm <\/b>geändert hat. Falls ja, sollen keine weiteren Aktionen folgen, falls nein, wurde die änderung vermutlich durch eine andere Aktion ausgelöst. <\/p>\n Löschvorgang dokumentieren<\/b><\/p>\n Das Dokumentieren des Löschens von Datensätzen ist eine interessante Sache: Wenn Sie einen Datensatz löschen, wohin sollen Sie dann sein Löschdatum schreiben<\/p>\n Ungeachtet der anderen Möglichkeiten gehen wir für diesen Fall davon aus, dass wir den Datensatz nicht wirklich löschen, sondern nur sein Löschdatum eintragen.<\/p>\n Das bedeutet natürlich, dass die Formulare und andere Objekte, die auf die Daten dieser Tabelle zugreifen, die Datenherkunft nach dem Löschdatum filtern müssen, um keine bereits gelöschten Daten mehr anzuzeigen.<\/p>\n Das ist wiederum eine interessante Anforderung, wenn es um das entsprechende Datenmakro geht: Dieses soll ja nun beim Löschen des Datensatzes nicht nur ein Löschdatum eintragen, sondern gleichzeitig auch noch dafür sorgen, dass der Datensatz gar nicht gelöscht wird.<\/p>\n Beides ist problematisch. Sie können das Löschen nur im Vor Löschung<\/b>-Ereignis verhindern, indem Sie dort einen Fehler auslösen. Dieser zeigt jedoch standardmäßig eine Fehlermeldung an.<\/p>\n Sie können allerdings etwa in Formularen oder unter VBA auf diesen Fehler reagieren und die Anzeige der entsprechenden Fehlermeldung verhindern.<\/p>\n Leider löst dies nicht das zweite Problem: Sie können im Vor Löschung<\/b>-Datenmakro definitiv keine änderung von Daten ausführen. Das heißt, dass wir kein Löschdatum in die Tabelle eintragen können.<\/p>\n Wer also gelöschte Datensätze in der Tabelle belassen möchte, kommt auf diesem Wege nicht weiter. Aber es gibt eine Alternative: Wir verwenden einfach das Nach Löschung<\/b>-Datenmakro. Darin können wir noch auf alle Daten des gelöschten Datensatzes zugreifen und diesen somit rekonstruieren – natürlich nicht, ohne das Löschdatum entsprechend einzutragen. Dieses Makro sieht wie in Bild 15 aus.<\/p>\n Bild 15: Kopieren statt Löschen<\/span><\/b><\/p>\n Vor Aktualisierung<\/b><\/p>\n Warum verwenden wir eigentlich das Nach Aktualisierung<\/b>-Datenmakro zum Schreiben der änderungshistorie und nicht das Makro Vor änderung<\/b> Vermutlich, weil wir sicher sein wollen, dass die Daten auch nicht mehr geändert werden, bevor wir die Historie anpassen.<\/p>\n Auch wenn wir in diesem Beitrag kein Beispiel mehr dazu liefern, wollen wir doch eine Eigenschaft dokumentieren, die nur im Vor änderung<\/b>-Datenmakro verfügbar ist: Sie heißt IstEingefügt<\/b> (englisch: IsInserted<\/b>) und gibt an, ob die aktuelle änderung durch das Neuanlegen eines Datensatzes ausgelöst wurde oder ob es sich um eine an einem bestehenden Datensatz durchgeführte änderung handelt.<\/p>\n Dies ist deshalb wichtig, weil das Makro Vor änderung <\/b>sowohl beim Anlegen eines neuen Datensatzes als auch bei änderungen an einem bestehenden Datensatz ausgelöst wird.<\/p>\n Das Makro Vor änderung <\/b>hat jedoch gegenüber den beiden Makros Nach Einfügen <\/b>und Nach Aktualisierung <\/b>einen deutlich eingeschränkten Befehlsumfang. So können Sie von dort beispielsweise keine Einträge in der Tabelle USysApplicationLog <\/b>speichern.<\/p>\n Verwendung der Alias-Eigenschaft<\/b><\/p>\n Sicher ist Ihnen in verschiedenen Makro-Aktionen die Alias-Eigenschaft aufgefallen, die wir bisher ignoriert haben. Diese Eigenschaft hat prinzipiell die gleiche Funktion wie unter SQL.<\/p>\n Immer, wenn Sie ein Alias festlegen können, greifen Sie auf eine Datensatzgruppe mit einem oder mehreren Datensätzen zu.<\/p>\n Sie können dieser Datensatzgruppe dann statt des Tabellennamens ein Alias wie beispielsweise T1<\/b>, T2 <\/b>oder T3 <\/b>zuweisen. In den folgenden Aktionen greifen Sie dann auf diese Alias-Bezeichnungen zu, was erstens oft Schreibarbeit spart und zweitens meist übersichtlicher ist.<\/p>\n Drittens kann es ja sein, dass Sie einmal einen Tabellennamen ändern (auch wenn das nur in frühen Phasen der Entwicklung einer Anwendung geschehen sollte).<\/p>\n Dann brauchen Sie den Tabellennamen nicht an jeder Stelle zu ändern, sondern nur dort, wo Sie das Alias eingetragen haben.<\/p>\n Debuggen<\/b><\/p>\n Ein Debuggen wie unter VBA ist beim Programmieren von Datenmakros nicht möglich. Ein nützliches Hilfsmittel ist jedoch die ProtokollierenEreignis<\/b>-Aktion, mit der Sie zu fast jeder Gelegenheit Ausdrücke in die Tabelle USysApplicationLog <\/b>schreiben können.<\/p>\n Test der Datenmakros <\/p>\n Datenmakros wirken wirklich universell: Egal, ob Sie gleich in der Tabelle änderungen an den Daten vornehmen, ob Sie dies über eine Abfrage oder ein Formular erledigen oder gar eine der dafür vorgesehenen VBA-Techniken verwenden: Datenmakros werden immer ausgeführt.<\/p>\n Verschachtelte Daten anlegen<\/b><\/p>\n Wenn Sie als Reaktion auf das Anlegen, ändern oder Löschen eines Datenmakros einen Datensatz in einer Tabelle anlegen möchten und anschließend auf den Primärschlüsselwert dieses Datensatzes zugreifen möchten, können Sie diesen mit der Funktion LetztesErstellenDatensatzID <\/b>abrufen.<\/p>\n Diese Funktion arbeitet nur für solche Datensätze, die tatsächlich mit der Aktion DatensatzErstellen <\/b>(englisch: CreateEntry<\/b>) erstellt wurden.<\/p>\n Datenmakros kommen im XML-Format<\/b><\/p>\n Möglicherweise machen Sie sich Gedanken, wie Sie beispielsweise allen Tabellen Ihrer Datenbank Makros zum Speichern der änderungshistorie hinzufügen sollen – immerhin ist der Makro-Editor zwar gegenüber früher verbessert, aber Sie können beispielsweise nicht per VBA darauf zugreifen (zumindest nicht offensichtlich).<\/p>\n Für das Hinzufügen vieler ähnlicher Datenmakros, die sich auf die Felder der Tabelle beziehen, können Sie aber per VBA-Code zumindest den entsprechenden XML-Code erstellen und brauchen diesen einfach nur noch in das Datenmakro einzufügen.<\/p>\n Datenmakros werden nämlich vollständig im XML-Format gespeichert. Sie können dies leicht nachvollziehen, indem Sie den Inhalt oder einen Teil des Inhalts eines Datenmakros kopieren und in einen Texteditor oder auch ins VBA-Fenster einfügen. Dort erkennen Sie den Aufbau des Makros im XML-Format. Dies gilt übrigens für alle Makros unter Access 2010.<\/p>\n Zusammenfassung und Ausblick<\/b><\/p>\n Datenmakros sind ein faszinierendes Werkzeug. Endlich können auch Access-Entwickler von einem Trigger-ähnlichen Konstrukt profitieren, das in der Welt der SQL-Server längst gang und gäbe ist.<\/p>\n Zu verdanken haben wir dies wohl der Tatsache, dass das Access-Entwicklerteam seit der Version 2007 von Access mit einer eigenen Version der Jet Engine arbeitet, der sogenannten ACE. So konnte man dort endlich Features integrieren, ohne Rücksicht auf die zahlreichen anderen Anwendungen zu nehmen, welche die Jet Engine verwenden.<\/p>\n Enthaltene Beispieldateien:<\/p>\n Datenmakros.accdb<\/p>\n![\"pic002.png\"](\"..\/fileadmin\/_temp_\/2011_01\/Datenmakros-web-images\/pic002.png\")
<\/p>\n![\"pic003.png\"](\"..\/fileadmin\/_temp_\/2011_01\/Datenmakros-web-images\/pic003.png\")
<\/p>\n="Datensatz angelegt am " & Datum()<\/pre>\n
![\"pic004.png\"](\"..\/fileadmin\/_temp_\/2011_01\/Datenmakros-web-images\/pic004.png\")
<\/p>\n![\"pic005.png\"](\"..\/fileadmin\/_temp_\/2011_01\/Datenmakros-web-images\/pic005.png\")
<\/p>\n![\"pic006.png\"](\"..\/fileadmin\/_temp_\/2011_01\/Datenmakros-web-images\/pic006.png\")
<\/p>\n![\"pic007.png\"](\"..\/fileadmin\/_temp_\/2011_01\/Datenmakros-web-images\/pic007.png\")
<\/p>\n\n
\n
\n
![\"pic008.png\"](\"..\/fileadmin\/_temp_\/2011_01\/Datenmakros-web-images\/pic008.png\")
<\/p>\n![\"pic009.png\"](\"..\/fileadmin\/_temp_\/2011_01\/Datenmakros-web-images\/pic009.png\")
<\/p>\n\n
![\"pic010.png\"](\"..\/fileadmin\/_temp_\/2011_01\/Datenmakros-web-images\/pic010.png\")
<\/p>\n![\"pic011.png\"](\"..\/fileadmin\/_temp_\/2011_01\/Datenmakros-web-images\/pic011.png\")
<\/p>\n![\"pic012.png\"](\"..\/fileadmin\/_temp_\/2011_01\/Datenmakros-web-images\/pic012.png\")
<\/p>\n![\"pic013.png\"](\"..\/fileadmin\/_temp_\/2011_01\/Datenmakros-web-images\/pic013.png\")
<\/p>\n![\"pic014.png\"](\"..\/fileadmin\/_temp_\/2011_01\/Datenmakros-web-images\/pic014.png\")
<\/p>\n![\"pic015.png\"](\"..\/fileadmin\/_temp_\/2011_01\/Datenmakros-web-images\/pic015.png\")
<\/p>\nDownloads zu diesem Beitrag<\/h3>\n