<\/p>\n
Ab Access 2010 können Sie mit den Datenmakros auf eine triggerähnliche Technik zugreifen. Damit definieren Sie direkt in der Tabelle, was beim Hinzufügen, ändern oder Löschen von Daten geschehen soll – unabhängig davon, ob diese änderung direkt in der Tabelle, über ein Formular, per Aktionsabfrage oder auch per VBA angestoßen wurde. Dieser Beitrag zeigt, wie Sie die Datenmakros nutzen können.<\/b><\/p>\n
Die Grundlagen zu Datenmakros haben wir bereits im Beitrag Datenmakros in Access 2010 <\/b>(www.access-im-unternehmen.de\/760<\/b>) besprochen. Im vorliegenden Beitrag schauen wir uns einige praktische Aspekte an und nehmen dabei das Thema Restriktionen in den Fokus.<\/p>\n
Bereits in früheren Versionen bietet Access ein paar Möglichkeiten, Daten mit Restriktionen zu versehen: beispielsweise mit eindeutigen Indizes, Primärschlüsselfeldern, Gültigkeitsregeln oder der Definition referentieller Integrität für Beziehungen und damit die Einschränkung der Werte für Fremdschlüsselfelder.<\/p>\n
Mit Datenmakros legen Sie praktisch beliebige Restriktionen fest und kombinieren Makros dabei nach Wunsch mit VBA-Funktionen.<\/p>\n
Da es hier um Restriktionen geht, kümmern wir uns in diesem Beitrag ausschließlich um die beiden Datenmakros Vor änderung <\/b>und Vor Löschung<\/b>. Beide werden ausgelöst, bevor eine änderung eines Datensatzes gespeichert beziehungsweise dieser endgültig gelöscht wird – es gibt also noch Gelegenheit, den Vorgang zu unterbrechen.<\/p>\n
Bearbeitung komplett unterbinden<\/b><\/p>\n
Dies kann eine grundsätzliche Option sein: Mit den Datenmakros Vor änderung <\/b>und Vor Löschung <\/b>lassen sich durchaus Regeln wie die folgenden festlegen:<\/p>\n Differenzierte Restriktionen<\/b><\/p>\n Es gibt jedoch auch die Möglichkeit, eine oder mehrere Regeln festzulegen, nach denen der Benutzer einen Datensatz hinzufügen, ändern oder löschen darf. Damit können Sie die oben beschriebenen Restriktionen etwas lockern – zum Beispiel, indem Sie das Hinzufügen von Datensätzen zu einer Tabelle grundsätzlich erlauben. Ein ändern oder Löschen hingegen soll nur in den ersten 15 Minuten nach dem Anlegen möglich sein – danach bleibt der Datensatz, wo und wie er ist.<\/p>\n Zusammenspiel mit VBA<\/b><\/p>\n Die für diese und komplizierte Restriktionen notwendigen Regeln können Sie direkt per Makro-Programmierung definieren. Sie können jedoch von Datenmakros aus auch VBA-Funktionen aufrufen, um komplexere Prüfungen in der gewohnten Umgebung abzubilden.<\/p>\n Außerdem zeigen wir Ihnen, wie Sie von VBA aus mit Datenmakros interagieren können, die etwa durch das Bearbeiten der betroffenen Datensätze per VBA ausgelöst wurden.<\/p>\n Datensätze einer Tabelle schützen<\/b><\/p>\n Als Beispiel dient eine einfache Tabelle namens tblAnreden<\/b>. Diese enthält in der Regel zwei bis drei Datensätze und sollte normalerweise nicht verändert werden (s. Bild 1).<\/p>\n Bild 2: Anlegen von Datenmakros in der Datenblattansicht einer Tabelle<\/span><\/b><\/p>\n Bis Access 2003 ließ sich dies mithilfe des Sicherheitssystems von Access regulieren, ab Access 2010 erledigen Sie dies mit Datenmakros. Schauen wir uns an, wie dies aussieht.<\/p>\n Am schnellsten prüfen lassen sich die änderungen an Datenmakros, wenn Sie diese öffnen, während die Tabelle in der Datenblattansicht angezeigt wird. Sie können die Wirkung dann direkt nach dem Schließen des Makro-Editors ausprobieren. Ein neues Datenmakro namens Vor änderung <\/b>oder Vor Löschung <\/b>legen Sie wie in Bild 2 an.<\/p>\n Bild 3: Dieses Makro löst einen Fehler aus, wenn der Benutzer einen Datensatz löschen will.<\/span><\/b><\/p>\n Voraussetzung hierfür ist allerdings, dass Sie in den Access-Optionen den Eintrag Aktuelle Datenbank|Anwendungsoptionen|Entwurfsänderungen für Tabellen in der Datenblattansicht aktivieren <\/b>angehakt haben.<\/p>\n Löschen verhindern<\/b><\/p>\n Wenn Sie verhindern möchten, dass ein Datensatz gelöscht wird, fügen Sie ein neues Datenmakro Vor Löschung <\/b>zur Tabelle hinzu. Darin legen Sie eine einzige Aktion namens AuslösenFehler <\/b>an. Als Parameter geben Sie dabei die Fehlernummer (hier 1<\/b>) sowie die Fehlerbeschreibung an, in diesem Fall Löschen nicht möglich<\/b> (s. Bild 3).<\/p>\n Bild 1: Beispieltabelle, deren Daten geschützt werden sollen<\/span><\/b><\/p>\n Dies bewirkt, dass Access beim Versuch, einen der Datensätze der Tabelle tblAnreden <\/b>zu löschen, eine Meldung wie in Bild 4 <\/span>einblendet.<\/p>\n Bild 4: Meldung beim Versuch, einen Datensatz zu löschen<\/span><\/b><\/p>\n Die Fehlermeldung wird nicht angezeigt – vielleicht erscheint diese aber, wenn Sie versuchen, einen Datensatz per VBA zu löschen Probieren wir es aus, indem wir schnell eine entsprechende Anweisung zusammenstellen und diese im Direktfenster des VBA-Editors absetzen:<\/p>\n Das Ergebnis überrascht ein wenig und sieht wie in Bild 5 aus. Als Fehlernummer kommt hier 3939 <\/b>zum Einsatz, was – um es vorwegzunehmen – scheinbar die Standardnummer für Fehler ist, die durch Datenmakros ausgelöst werden. Immerhin zeigt Access aber die angegebene Fehlermeldung an.<\/p>\n Bild 5: Beim Löschen per VBA erscheint eine völlig andere Fehlernummer.<\/span><\/b><\/p>\n Begnügen wir uns doch zunächst mit der Erkenntnis, dass wir in der Datenblattansicht und beim Löschen per Execute<\/b>-Anweisung eine entsprechende Meldung provozieren und das Löschen verhindern können.<\/p>\n ändern von Daten verhindern<\/b><\/p>\n Wie sieht es bei der änderung eines Datensatzes aus Eigentlich genau wie beim Löschen. Wenn ein Datensatz nicht geändert werden darf, legen Sie das Datenmakro Vor änderung <\/b>an.<\/p>\n Fügen Sie diesem die Aktion AuslösenFehler <\/b>hinzu und hinterlegen Sie eine entsprechende Meldung (s. Bild 6). Beim Versuch, einen Datensatz der Tabelle zu ändern, liefert Access die angegebene Meldung und verwirft die änderung.<\/p>\n Bild 6: Dieses Makro verhindert änderungen am Datensatz.<\/span><\/b><\/p>\n Hinzufügen von Daten verhindern<\/b><\/p>\n Probieren Sie nun einmal, der mit dem oben beschriebenen Datenmakro Vor änderung <\/b>ausgestatteten Tabelle einen neuen Datensatz hinzuzufügen.<\/p>\n Auch dies wird unterbunden, denn Access interpretiert das Hinzufügen eines neuen Datensatzes hier als änderung.<\/p>\n Was aber, wenn Sie eine spezifische Meldung ausgeben möchten, wenn der Benutzer unerlaubterweise versucht, einen Datensatz anzulegen Dann benötigen Sie eine Wenn<\/b>-Bedingung, die prüft, ob der Benutzer einen neuen Datensatz angelegt oder nur einen bestehenden Datensatz geändert hat.<\/p>\n Wie auch bei Triggern üblich, erlaubt Access in den beiden Makro-Aktionen Vor änderung <\/b>und Vor Löschung <\/b>den Zugriff auf zwei verschiedene Zustände des aktuell bearbeiteten Datensatzes: erstens auf den Datensatz vor der änderung und zweitens auf den Datensatz nach der änderung. Den geänderten Datensatz referenzieren Sie dabei mit dem Tabellennamen. Der Ausdruck [tblAnreden].[AnredeID] <\/b>liefert also den neuen Primärschlüsselwert des Datensatzes. Wenn Sie den Primärschlüsselwert des Datensatzes vor der änderung ermitteln möchten, nutzen Sie den Ausdruck [Alt].[AnredeID]<\/b>.<\/p>\n Dies gelingt nicht nur mit vorhandenen Datensätzen, sondern auch mit neuen. Und logischerweise sind die Werte der Felder eines Datensatzes vor dem Anlegen alle leer.<\/p>\n Auf einen neuen Datensatz prüfen<\/b><\/p>\n Um im Makro Vor änderung <\/b>zu prüfen, ob ein neuer Datensatz angelegt oder ein bestehender Datensatz geändert wurde, brauchen Sie nur den Inhalt eines Feldes zu prüfen, von dem Sie genau wissen, dass es nach dem Anlegen gefüllt ist.<\/p>\n Dies ist bei einem Primärschlüsselfeld, das als Autowertfeld ausgelegt ist, der Fall. Also prüfen wir den Ausdruck IstNull([Alt].[AnredeID])<\/b>. Ist dieser wahr, handelt es sich um einen neuen Datensatz, sonst um einen bestehenden Datensatz (s. Bild 7). Dementsprechend liefert Access beim Anlegen eines neuen Datensatzes die Meldung Sie dürfen dieser Tabelle keine Daten hinzufügen<\/b>.<\/p>\n Bild 7: Fallunterscheidung beim ändern eines Datensatzes: Neu oder geändert<\/span><\/b><\/p>\n Datensätze nur 15 Minuten nach dem Anlegen ändern<\/b><\/p>\n Damit haben Sie bereits ein Beispiel für eine Bedingung kennengelernt. Schauen wir uns ein weiteres Beispiel an: Dabei soll der Benutzer einer Tabelle zwar beliebig neue Datensätze hinzufügen, diese aber nur innerhalb von 15 Minuten nach dem Anlegen wieder löschen oder ändern können.<\/p>\n Dazu verwenden wir eine Tabelle namens tblTaetigkeiten<\/b> mit den Feldern TaetigkeitID<\/b>, Taetigkeit <\/b>und AngelegtAm<\/b> (s. Bild 8).<\/p>\n Bild 8: Tabelle mit Zeitstempel<\/span><\/b><\/p>\n <\/p>\n Den Wert des Feldes können Sie auf gewohnte Weise mit der Standardwert<\/b>-Eigenschaft des Feldes festlegen. Sie können natürlich auch einen Befehl im Datenmakro Vor änderung <\/b>unterbringen. Der Befehl heißt FestlegenFeld<\/b>. Für die Parameter Name <\/b>und Feld <\/b>legen Sie dabei die beiden Ausdrücke AngelegtAm <\/b>und Jetzt() <\/b>fest.<\/p>\n Dies soll geschehen, wenn soeben ein neuer Datensatz angelegt wurde. Damit das Makro das Anlegedatum nur in diesem Fall einträgt, prüft es vorher, ob das Primärschlüsselfeld TaetigkeitID <\/b>den Wert Null <\/b>enthält – und dies ist nur bei einem neuen Datensatz der Fall.<\/p>\n Wenn der Datensatz nicht frisch angelegt wurde, soll eine weitere Prüfung erfolgen – nämlich die, ob das Anlegen des Datensatzes bereits vor mehr als 15 Minuten geschehen ist. In diesem Fall soll die änderung unter Angabe einer entsprechenden Meldung unterbunden werden. Der Ausdruck, der den zeitlichen Abstand zum Erstellungszeitpunkt prüft, lautet folgendermaßen:<\/p>\n Dies liest sich so: Wenn die Differenz aus der aktuellen Zeit und dem Erstellungszeitpunkt größer als 1\/96 ist, soll ein Fehler ausgelöst und eine Meldung ausgegeben werden.<\/p>\n Datumsangaben werden ja intern als Double<\/b>-Zahlen gespeichert, wobei die Zahl vor dem Komma dem Datum und die Zahl hinter dem Komma der Uhrzeit entspricht. 1\/96 liefert den entsprechenden Bruchteil eines Tages, nämlich eine Viertelstunde. Das komplette Makro zeigt Bild 9.<\/p>\n Bild 9: Bei neuen Datensätzen Anlegedatum eintragen, sonst prüfen, ob der Datensatz bereits älter als 15 Minuten ist und dann änderungen unterbinden<\/span><\/b><\/p>\n Einfachere Variante<\/b><\/p>\n Wenn Sie das Eintragen des Anlegedatums per Standardwert des Feldes AngelegtAm <\/b>durchführen, kann das Datenmakro vereinfacht werden (siehe Beispieltabelle tblTaetigkeiten_1<\/b>).<\/p>\n Sie brauchen dort nicht vorab zu prüfen, ob ein neuer Datensatz angelegt wurde – dies geschieht impliziert im folgenden Ausdruck:<\/p>\n Wurde der Datensatz soeben angelegt, aber noch nicht gespeichert, liefert [Alt].[AngelegtAm] <\/b>den Wert NULL <\/b>zurück. Der Ausdruck Jetzt() – NULL <\/b>liefert wiederum NULL<\/b>, und NULL > 1\/96<\/b> ebenfalls.<\/p>\n Das Ergebnis des gesamten Ausdrucks ist also NULL <\/b>und somit ungleich True <\/b>– die im Wenn…Dann<\/b>-Konstrukt enthaltenen Anweisungen werden nicht ausgeführt.<\/p>\n In den ersten 15 Minuten nach dem Anlegen des Datensatzes liefert die Bedingung den Wert False<\/b>, das Bearbeiten des Datensatzes innerhalb dieses Zeitraums ist also erlaubt. Erst nach 15 Minuten lautet das Ergebnis des Ausdrucks True <\/b>und der Fehler innerhalb der Wenn…Dann<\/b>-Bedingung wird ausgelöst. Dieses Makro zeigt Bild 10.<\/p>\n Bild 10: Die Restriktion impliziert die Prüfung des NULL-Wertes.<\/span><\/b><\/p>\n Standardwert: Per Eigenschaft oder per Makro<\/b><\/p>\n Beim Experimentieren mit den Datenmakros ist beiläufig aufgefallen, dass die beiden Methoden zum Festlegen eines Standardwertes durchaus unterschiedliche Ergebnisse liefern. Wenn Sie die Eigenschaft Standardwert <\/b>eines Feldes wie etwa AngelegtAm <\/b>auf den Ausdruck Now() <\/b>einstellen, belegt Access dieses Feld bereits beim Öffnen der Tabelle\/Abfrage mit dem angegebenen Wert vor (s. Bild 11).<\/p>\n Bild 11: Standardwerte werden gleich beim Anzeigen des neuen Datensatzes vorbelegt.<\/span><\/b><\/p>\n Dies gilt auch für gebundene Formulare gleich in welcher Ansicht: Sobald das Formular geöffnet wurde, wird der Standardwert für einen neuen Datensatz festgelegt. Erst das Aktualisieren der Datensatzgruppe ändert den Standardwert entsprechend der angegebenen Funktion.<\/p>\n Probleme entstehen dadurch, wenn Sie in einem Formular zunächst die vorhandenen Datensätze betrachten oder bearbeiten und erst dann einen neuen Datensatz anlegen. Dieser erhält dann als Anlegedatum nicht den gewünschten Wert, sondern den Zeitpunkt des Öffnens des Formulars.<\/p>\n Wenn das Anlegedatum oder ähnliche Werte für die Handhabung der Daten wichtig sind, sollten Sie daher besser eine alternative Vorgehensweise wählen. Eine davon ist der Einsatz des oben erwähnten Datenmakros, das den Anlegezeitpunkt tatsächlich erst beim Anlegen des Datensatzes festlegt.<\/p>\n Löschen nach mehr als 15 Minuten verhindern<\/b><\/p>\n Wenn ein Datensatz nur innerhalb der ersten 15 Minuten nach dem Anlegen geändert werden darf, sollte dies auch für den Löschvorgang gelten. Dies erreichen Sie am Beispiel der Tabelle tblTaetigkeiten_1 <\/b>mit dem Makro aus Bild 12.<\/p>\n Bild 12: Das Löschen eines neuen Datensatzes ist nur innerhalb der ersten 15 Minuten möglich.<\/span><\/b><\/p>\n Restriktionen in Datenmakros und VBA<\/b><\/p>\n Die bisherigen Ausführungen liefern die Grundlage für den Praxiseinsatz. Dort werden Daten nicht direkt in Tabellen oder Abfragen geändert, sondern in Formularen oder per VBA. Als Erstes schauen wir uns an, wie sich die Zusammenarbeit zwischen Datenmakros und VBA gestaltet, später kommen dann die Formulare hinzu.<\/p>\n Weiter oben haben Sie beim Aufruf einer DELETE<\/b>-Anweisung über die Execute<\/b>-Methode bereits ein Beispiel dafür kennengelernt, dass Datenmakros auch funktionieren, wenn die Daten einer mit Datenmakros versehenen Tabelle per VBA geändert werden.<\/p>\n Entwickler- und Administratormodus für Datenmakros<\/b><\/p>\n Die mit Datenmakros geschaffenen Vorrichtungen zum Schützen der Daten vor unbeabsichtigten oder unerwünschten änderungen erweisen sich während der Entwicklung der Anwendung und eventuell auch im späteren Einsatz manchmal als Hindernis.<\/p>\n Auch wenn Sie, wie oben beispielhaft beschrieben, das ändern von Daten nach einer gewissen Zeitspanne nach dem Anlegen unterbinden möchten, möchten Sie beim Entwickeln angelegte Daten doch vielleicht wieder entfernen.<\/p>\n Oder ein Mitarbeiter gibt einmal Daten ein und stellt erst nach Ablauf des festgelegten Zeitraums zum ändern fest, dass er die Daten noch korrigieren möchte. Dann sollte zumindest ein Administrator in der Lage sein, solche Daten noch zu ändern.<\/p>\n Für solche Zwecke können Sie einen Entwickler- oder Administratormodus für eine Anwendung vorsehen.<\/p>\n Ob dieser Modus aktiviert ist oder nicht, soll der Einfachheit halber durch folgende Variable festgelegt werden:<\/p>\n Den Wert dieser Variablen stellen Sie zu Versuchszwecken einfach im Direktfenster ein. Den Administratormodus aktivieren Sie mit dieser Anweisung:<\/p>\n Damit deaktivieren Sie den Administratormodus wieder:<\/p>\n Damit das entsprechende Datenmakro den Wert dieser Variablen abfragen kann, legen Sie eine kleine VBA-Funktion an:<\/p>\n Diese Funktion müssen Sie nun nur noch in die Datenmakros integrieren. Wie dies gelingt, zeigt das Makro Vor änderung <\/b>der Tabelle tblTaetigkeiten_Mit_Adminmodus<\/b> (s. Bild 13). Das Makro fragt gleich in der ersten Zeile den Wert der Funktion IstAdmin <\/b>ab.<\/p>\n Bild 13: Das Makro wird im Admin-Modus nach der ersten Anweisung gestoppt.<\/span><\/b><\/p>\n Lautet das Ergebnis True<\/b>, wird das Datenmakro angehalten, sonst wird es fortgesetzt. Sie können diese Funktionalität nun ausprobieren, indem Sie die beiden Anweisungen von oben im Direktfenster eingeben und jeweils versuchen, Datensätze, die älter als 15 Minuten sind, zu ändern. Bei aktiviertem Administrator-Modus gelingt dies nun.<\/p>\n Makro-Anweisungen auslagern<\/b><\/p>\n Nun, da Sie wissen, dass Sie das Ermitteln einer Bedingung in eine VBA-Funktion auslagern können, fragen Sie sich sicher, ob dies auch für komplette Makros funktioniert. Ja, dies ist grundsätzlich möglich: Sie benötigen einfach nur eine entsprechende VBA-Funktion.<\/p>\n Beim Aufruf müssen Sie dieser Funktion natürlich alle für die Ausführung der Funktion benötigten Parameter übergeben. Es gibt allerdings eine wichtige Einschränkung: Das Unterbinden der änderung eines Datensatzes gelingt nur durch die Makro-Aktion AuslösenFehler<\/b>. Damit steht auch fest, dass zumindest beim direkten Zugriff auf Tabellen oder Abfragen die Fehlermeldung der Aktion AuslösenFehler <\/b>des Datenmakros angezeigt werden muss.<\/p>\n Datenmakros per VBA auslösen<\/b><\/p>\n Die änderungen, die zum Auslösen von Datenmakros führen, können Sie natürlich nicht nur durch direkte Bearbeitung provozieren. Dies schaffen Sie auch, wenn Sie einen Datensatz einer mit Datenmakros ausgestatteten Tabelle per VBA bearbeiten und speichern beziehungsweise löschen. Die Auswirkungen können Sie sich anhand der Tabelle tblAnreden <\/b>und des Versuchs, einen neuen Datensatz anzulegen, in Bild 14 ansehen.<\/p>\n Bild 16: Fehlernummer und -meldung in einer Eigenschaft<\/span><\/b><\/p>\n Provozierte Fehler durch Datenmakros behandeln<\/b><\/p>\n Wenn per VBA Daten geändert werden sollen, die durch ein Datenmakro vor änderungen geschützt werden, löst dies ebenfalls einen Laufzeitfehler aus. Die Frage ist nun: Wie präsentieren wir dem Benutzer die entsprechende Meldung Die eingebaute Fehlermeldung ist wohl kaum geeignet, zudem sie dem Benutzer in der Vollversion von Access die Möglichkeit gibt, den Code zu debuggen (s. Bild 15).<\/p>\n Bild 14: Fehlermeldung beim Versuch, einen neuen Datensatz per VBA anzulegen<\/span><\/b><\/p>\n Ein erster Versuch, eine Fehlerbehandlung zu integrieren, gelingt schon recht gut. Die folgende Prozedur deaktiviert die integrierte Fehlerbehandlung und prüft unmittelbar nach dem Ausführen der Aktionsabfrage, ob der Fehler mit der Nummer 3939<\/b> aufgetreten ist. Ist dies der Fall, liefert ein Meldungsfenster genau den Text, der im Datenmakro festgelegt wurde:<\/p>\n Wenn Sie mit der Anzeige einer Fehlermeldung leben können, reicht dieser Ansatz aus. Interessant wird es, wenn Sie in Abhängigkeit vom Fehler noch weitere Schritte einleiten müssen, die über die Fehleranzeige hinausgehen. Eine Fehlernummer zur Qualifizierung des genauen Fehlers fehlt, denn Makrofehler liefern immer den Fehler mit der Nummer 3939<\/b> – jedoch mit wechselnden Fehlermeldungen. Sie können nun entweder die Fehlermeldung selbst analysieren und in Abhängigkeit davon weitere Maßnahmen ergreifen. Dazu wäre es unter anderem denkbar, statt einer Fehlerbeschreibung einfach ein zweites Mal die Fehlernummer anzugeben – diese könnte dann individuell ausgewertet werden. Es gäbe dann allerdings keine aussagekräftige Fehlermeldung mehr, wenn der Fehler durch direkte Eingabe etwa in einem Datenblatt in einem Unterformular ausgelöst würde. Doch auch das ist kein Problem: Fehler in Datenmakros lassen sich auch in Formularen abfangen und behandeln, wie Sie gleich erfahren werden.<\/p>\n\n
![\"pic002.png\"](\"..\/fileadmin\/_temp_\/2012_02\/RestriktionenMitDatenmakros-web-images\/pic002.png\")
<\/p>\n![\"pic003.png\"](\"..\/fileadmin\/_temp_\/2012_02\/RestriktionenMitDatenmakros-web-images\/pic003.png\")
<\/p>\n![\"pic001.png\"](\"..\/fileadmin\/_temp_\/2012_02\/RestriktionenMitDatenmakros-web-images\/pic001.png\")
<\/p>\n![\"pic004.png\"](\"..\/fileadmin\/_temp_\/2012_02\/RestriktionenMitDatenmakros-web-images\/pic004.png\")
<\/p>\nCurrentDB.Execute "DELETE FROM tblAnreden WHERE AnredeID = 3"<\/pre>\n
![\"pic005.png\"](\"..\/fileadmin\/_temp_\/2012_02\/RestriktionenMitDatenmakros-web-images\/pic005.png\")
<\/p>\n![\"pic006.png\"](\"..\/fileadmin\/_temp_\/2012_02\/RestriktionenMitDatenmakros-web-images\/pic006.png\")
<\/p>\n![\"pic007.png\"](\"..\/fileadmin\/_temp_\/2012_02\/RestriktionenMitDatenmakros-web-images\/pic007.png\")
<\/p>\n![\"pic008.png\"](\"..\/fileadmin\/_temp_\/2012_02\/RestriktionenMitDatenmakros-web-images\/pic008.png\")
<\/p>\nJetzt()-[Alt].[AngelegtAm]>1\/96<\/pre>\n
![\"pic010.png\"](\"..\/fileadmin\/_temp_\/2012_02\/RestriktionenMitDatenmakros-web-images\/pic010.png\")
<\/p>\nJetzt()-[Alt].[AngelegtAm]>1\/96<\/pre>\n
![\"pic009.png\"](\"..\/fileadmin\/_temp_\/2012_02\/RestriktionenMitDatenmakros-web-images\/pic009.png\")
<\/p>\n![\"pic011.png\"](\"..\/fileadmin\/_temp_\/2012_02\/RestriktionenMitDatenmakros-web-images\/pic011.png\")
<\/p>\n![\"pic012.png\"](\"..\/fileadmin\/_temp_\/2012_02\/RestriktionenMitDatenmakros-web-images\/pic012.png\")
<\/p>\nPublic bolIstAdmin As Boolean<\/pre>\n
bolIstAdmin = True<\/pre>\n
bolIstAdmin = False<\/pre>\n
Public Function IstAdmin() As Boolean\r\n IstAdmin = bolIstAdmin\r\nEnd Function<\/pre>\n
![\"pic013.png\"](\"..\/fileadmin\/_temp_\/2012_02\/RestriktionenMitDatenmakros-web-images\/pic013.png\")
<\/p>\n![\"pic016.png\"](\"..\/fileadmin\/_temp_\/2012_02\/RestriktionenMitDatenmakros-web-images\/pic016.png\")
<\/p>\n![\"pic014.png\"](\"..\/fileadmin\/_temp_\/2012_02\/RestriktionenMitDatenmakros-web-images\/pic014.png\")
<\/p>\nPublic Sub AnredeAnlegen()\r\n Dim db As DAO.Database\r\n Set db = CurrentDb\r\n On Error Resume Next\r\n db.Execute "INSERT INTO tblAnreden(Anrede) VALUES(''Mein Lieber'')"\r\n Select Case Err.Number\r\n Case 3939\r\n MsgBox Err.Description, vbOKOnly + vbExclamation, "Datenfehler"\r\n End Select\r\n Set db = Nothing\r\nEnd Sub<\/pre>\n
![\"pic015.png\"](\"..\/fileadmin\/_temp_\/2012_02\/RestriktionenMitDatenmakros-web-images\/pic015.png\")
<\/p>\n