<\/p>\n
Beim Löschen von Daten aus Tabellen, die verknüpfte Daten in anderen Tabellen enthalten, können verschiedene Probleme auftauchen – mal werden Daten mitgelöscht, die man noch braucht, mal bleiben Daten erhalten, die eigentlich ebenfalls gelöscht werden sollen. Die referentielle Integrität und die Löschweitergabe sind eine Möglichkeit, verknüpfte Daten zu löschen, aber ihr Einsatz will sorgfältig durchdacht sein. Diese und andere Techniken erläutert der vorliegende Beitrag.<\/b><\/p>\n
Genau wie bei den Beziehungen gibt es auch bei den Varianten, ob und wie verknüpfte Datensätze eines Datensatzes einer Tabelle mitgelöscht werden sollen: Bei den Beziehung spricht man gemeinhin von der 1:n-, der m:n- und der 1:1-Beziehung, wobei letztlich alles auf der 1:n-Beziehung basiert. Das Datenmodell der Beispieldatenbank (siehe Bild 1) liefert ein paar Beziehungstypen, deren Verhalten in Bezug auf das Löschen von Datensätzen wir uns im folgenden ansehen werden.<\/p>\n
![\"pic001.png\"](\"..\/fileadmin\/_temp_\/2010_03\/VerknuepfteDatenLoeschen-web-images\/pic001.png\")
<\/p>\n
Bild 1: Datenmodell der Beispieldatenbank<\/span><\/b><\/p>\n Fall 1: Lookup-Tabellen<\/b><\/p>\n Lookup-Tabellen sind Tabellen, die Details zur Haupttabelle liefern und diese zur Auswahl anbieten – meist über ein Nachschlage- beziehungsweise Kombinationsfeld. Ein Beispiel ist die Tabelle tblAnreden<\/b>, welche die verschiedenen Werte für das Feld AnredeID <\/b>der Tabelle tblAnreden <\/b>liefert.<\/p>\n Wie soll das Löschverhalten hier aussehen Das ist einfach: Weder das Löschen eines Mitarbeiters noch einer Anrede sollte sich auf die Datensätze der jeweils anderen Tabelle auswirken. Aber: Es dürfen zwar Datensätze der Tabelle tblMitarbeiter <\/b>gelöscht werden, denen eine Anrede zugewiesen wurde, aber keine Anrede, die bereits einem Mitarbeiter zugewiesen wurde.<\/p>\n Dies realisiert man über die Festlegung referentieller Integrität für die Beziehung zwischen beiden Tabellen. Diese kann man nur im Beziehungen-Fenster einstellen, und zwar am schnellsten durch einen Doppelklick auf den Beziehungspfeil. Dadurch erscheint der Dialog aus Bild 2, in dem wir bereits referentielle Integrität festgelegt haben.<\/p>\n Bild 2: Referentielle Integrität für die Beziehung zu einer Lookup-Tabelle<\/span><\/b><\/p>\n Was genau bewirkt referentielle Integrität in diesem Fall Beim Versuch, einen Datensatz der Tabelle tblAnreden <\/b>zu löschen, dessen Primärschlüsselwert bereits im Fremdschlüsselfeld AnredeID <\/b>der Tabelle tblMitarbeiter <\/b>gespeichert ist, zeigt Access die Meldung aus Bild 3 an. Sie besagt, dass der Datensatz nicht gelöscht werden kann, da eine andere Tabelle in Beziehung stehende Datensätze enthält.<\/p>\n Bild 3: Die referentielle Integrität verhindert das Löschen verknüpfter Daten – aber nur in eine Richtung.<\/span><\/b><\/p>\n Wenn Sie in diesem Fall keine referentielle Integrität definiert hätten, könnte ein Benutzer leicht Datensätze der Tabelle tblAnreden <\/b>löschen.<\/p>\n Andererseits besteht ja auch die Möglichkeit, zusätzlich zur referentiellen Integrität die Löschweitergabe zu aktivieren. Manche Entwickler machen dies aus Unwissenheit immer, obwohl es wenig erheiternde Folgen haben könnte. Löschweitergabe für die Beziehung zwischen tblMitarbeiter <\/b>und tblAnreden <\/b>würde zum Beispiel bedeuten, dass beim Löschen einer Anrede auch alle Mitarbeiter gelöscht würden, welche mit dieser Anrede verknüpft sind.<\/p>\n Für 1:n-Lookupbeziehungen ist die Festlegung referentieller Integrität ohne Löschweitergabe also die richtige Einstellung.<\/p>\n Fall 2: 1:n-Beziehungen<\/b><\/p>\n Im Gegensatz zu 1:n-Lookupbeziehungen gibt es auch „echte“ 1:n-Beziehungen, bei denen nicht nur der Inhalt eines Feldes ausgegliedert in eine verknüpfte Tabelle wurde, sondern die in der Regel zwei Tabellen verknüpfen, die Abbildungen echter Objekte sind. In der Beispieldatenbank sind dies Kunden und Projekte, wobei für jedes Projekt über das Feld KundeID <\/b>der Kunde ausgewählte werden kann, für den dieses Projekt durchgeführt wird.<\/p>\n Hier gilt wie bei der Lookup-Beziehung: Wenn keine referentielle Integrität festgelegt ist, dann kann der Benutzer sowohl Kunden als auch Projekte unabhängig voneinander löschen, was sicher nicht gewünscht ist.<\/p>\n Mit referentieller Integrität können Sie ein Projekt löschen, ohne das der Kundendatensatz davon berührt wird, aber Sie können nur Kunden löschen, denen keine Projekte zugeteilt wurden. Besitzt ein Kunde mindestens ein Projekt, kann er nicht ohne vorheriges Löschen entfernt werden.<\/p>\n Auch hier ist die Aktivierung der Löschweitergabe vorsichtig einzusetzen, aber immerhin unter Umständen nützlich: Beim Löschen eines Kunden würden auch all seine Projekte gelöscht. Wenn es sich um einen Kunden handelt, dessen Projektdaten nicht mehr benötigt werden oder der samt Projektdaten archiviert wurde, kann man ruhigen Gewissens den kompletten Kunden samt seiner Projekte aus der Datenbank entfernen.<\/p>\n m:n-Beziehungen<\/b><\/p>\n Bei m:n-Beziehungen wie etwa der zwischen Projekten und Mitarbeitern ist referentielle Integrität ebenfalls Pflicht, denn sonst könnte man Datensätze der Tabellen tblMitarbeiter <\/b>oder tblProjekte <\/b>löschen, ohne dass eventuell damit verknüpfte Datensätze der Verknüpfungstabelle tblProjektmitarbeiter <\/b>entfernt werden.<\/p>\n Wenn man mit der Löschweitergabe arbeiten wollte, kann man diese unabhängig voneinander für eine der beiden 1:n-Beziehungen einer m:n-Beziehung einsetzen – egal, ob die andere Beziehung mit referentieller Integrität und gegebenenfalls auch mit Löschweitergabe definiert ist.<\/p>\n Der Datensatz der m:n-Verknüpfungstabelle wird in jedem Falle gelöscht, da nur er selbst per Fremdschlüsselfeld auf andere Tabellen verweist. Dementsprechend lassen sich auch Datensätze der Verknüpfungstabelle ohne weitere löschen.<\/p>\n Verknüpfungen mehrerer Tabellen<\/b><\/p>\n Manchmal zieht die referentielle Integrität weiter Kreise: In unserem Beispieldatenmodell sind beispielsweise die Beziehungen zwischen den Tabellen tblKunden <\/b>und tblProjekte <\/b>sowie tblProjekte <\/b>und tblProjektmitarbeiter <\/b>mit referentieller Integrität definiert. Angenommen, wir würden Löschweitergabe für die Beziehung zwischen tblKunden <\/b>und tblProjekte <\/b>definieren, damit beim Löschen eines Kunden auch seine Projekte gelöscht werden, aber es gäbe über die Tabelle tblProjektmitarbeiter <\/b>bereits eine Zuweisung des Projekts zu einem oder mehreren Mitarbeitern, dann geschieht beim Löschen des Kunden folgendes:<\/p>\n <\/p>\n Benutzergesteuertes Behandlung von Löschvorgängen<\/b><\/p>\n Nun möchten Sie den Benutzer der Anwendung sicher nicht mit den (hier zugegebenermaßen aussagekräftigen) Meldungen von Access allein lassen, sondern eigene Meldungen liefern und dem Benutzer weitere Möglichkeiten beim Scheitern von Löschvorgängen aufzeigen.<\/p>\n Löschen von Kunden mit und ohne Projekte<\/b><\/p>\n Bild 4 zeigt eine ganz einfache Konfiguration aus Haupt- und Unterformular zum Bearbeiten von Kunden und deren Projekten. Das Hauptformular verwendet die Tabelle tblKunden <\/b>als Datenherkunft, das Unterformular die Tabelle tblProjekte<\/b>. Die beiden Eigenschaften Verknüpfen von <\/b>und Verknüpfen nach <\/b>des Unterformularsteuerelements sorgen dafür, dass das Unterformular jeweils die zum Kunden des Hauptformulars passenden Projekte anzeigt.<\/p>\n Bild 4: Ein einfaches Formular zur Darstellung von 1:n-Beziehungen<\/span><\/b><\/p>\n Wenn wir nun versuchen, den aktuellen Kunden zu löschen (Klick auf den Datensatzmarkierer des Hauptformulars, dann Entfernen-Taste betätigen), verweigert Access erwartungsgemäß den Dienst und zeigt den Grund in einer Meldung an: Der Datensatz könne nicht gelöscht werden, weil die Tabelle tblProjekte <\/b>verknüpfte Datensätze enthielte.<\/p>\n Wie können wir diese Meldung unterdrücken und im Falle des Versuchs, einen Kunden mitsamt seinen Projekten zu löschen, dafür sorgen, dass dies auch klappt<\/p>\n Die einfachste Variante ist natürlich, dem Kunden ein Meldungsfenster zu präsentieren, dass ihn darauf hinweist, dass er einfach vorher alle Projekte löschen soll.<\/p>\n Auch dies stellt unerfahrene Access-Entwickler vor die Frage: Wie soll ich in den Löschversuch und die damit verbundene Access-eigene Meldung eingreifen und dem Benutzer meine eigene Meldung unterjubeln<\/p>\n Es gibt (mindestens) drei Möglichkeiten, die sich unter anderem dadurch unterscheiden, ob die Löschweitergabe zwischen den Tabellen tblKunden <\/b>und tblProjekte <\/b>aktiviert ist:<\/p>\n Löschvorgang vor dem Löschen steuern – mit Löschweitergabe<\/p>\n Das die Löschweitergabe Access einen Freifahrtschein gibt, Daten samt verknüpfter Daten ohne Rückfrage wegzupusten, wissen Sie bereits.<\/p>\n Wenn Sie Löschweitergabe aktivieren und den Benutzer vorwarnen möchten, bevor er nicht nur einen, sondern gleich noch eine Reihe verknüpfter Datensätze löscht, verwenden Sie das Ereignis Beim Löschen<\/b>.<\/p>\n Legen Sie eine Ereignisprozedur dafür an, indem Sie das Hauptformular im Entwurf öffnen und dann im Eigenschaftsfenster für die Eigenschaft Beim Löschen <\/b>den Wert [Ereigniseigenschaft] <\/b>auswählen. Beim Klick auf die Schaltfläche neben der Eigenschaft erscheint der VBA-Editor und zeigt die leere Ereignisprozedur an, die Sie wie in Listing 1 füllen.<\/p>\n Listing 1: Vorwarnung, falls verknüpfte Datensätze mitgelöscht werden sollen<\/p>\n Die Routine wird nach dem Absenden des Löschbefehls, aber vor dem Löschvorgang ausgeführt, damit dieser durch das Setzen des Parameters Cancel <\/b>auf den Wert True <\/b>noch abgebrochen werden kann.<\/p>\n Sie zählt per DCount <\/b>die Anzahl der verknüpften Datensätze aus der Tabelle tblProjekte<\/b>. Wenn die Anzahl größer 0 <\/b>ist, erscheint eine Meldung, die den Benutzer darauf hinweist, dass die Projekte des Kunden ebenfalls gelöscht werden.<\/p>\n Mit einem Klick auf OK <\/b>setzt der Benutzer diesen Vorgang fort, mit Abbrechen <\/b>kann er den kompletten Vorgang stoppen.<\/p>\n Die Beispielformulare hierzu heißen frmKundenProjekte_MitLoeschweitergabe <\/b>und sfmKundenProjekte_MitLoeschweitergabe<\/b>.<\/p>\n Löschvorgang vor dem Löschen steuern – diesmal ohne Löschweitergabe<\/b><\/p>\n Wenn keine Löschweitergabe definiert ist, brauchen Sie dem Formular zumindest keine Sicherheitsmaßnahmen unterzujubeln, damit der Benutzer keine Kunden löscht, denen noch Projekte anhängen. Es erscheint dann einfach ein Hinweis, dass der Datensatz wegen der vorhandenen verknüpften Datensätze nicht gelöscht werden kann.<\/p>\n Wir wollen ihm aber die Möglichkeit schaffen, dies alles, soweit gewünscht, in einem Schritt zu erledigen. Wie dies funktionert, können Sie den Beispielformularen frmKundenProjekte_VorDemLoeschen <\/b>beziehungsweise sfmKundenProjekte_VorDemLoeschen <\/b>entnehmen.<\/p>\n Dort haben wir ebenfalls eine Routine untergebracht, die durch das Ereignis Beim Löschen <\/b>ausgelöst wird. Die dortige Variante darf ein paar Handschläge mehr erledigen – zumindest, wenn der Benutzer den Kunden samt Projekten löschen möchte. Auch hier werden die verknüpften Datensätze vorher gezählt.<\/p>\n Wenn der Benutzer den Löschvorgang durchführen möchte, werden allerdings zuvor alle verknüpften Projekte per Code gelöscht. Auf diese Weise entziehen wir der Access-Meldung mit den Hinweis auf die verknüpften Datensätze die Daseinsberechtigung, das Löschen des Kunden-Datensatzes erfolgt anschließend wie gewünscht.<\/p>\n Access-Meldung beim Löschen per Fehlerbehandlung unterbinden<\/b><\/p>\n Die dritte Variante kommt ebenfalls ohne Löschweitergabe zwischen den Tabellen tblProjekte <\/b>und tblKunden <\/b>aus. Sie baut darauf, dass das Löschen eines Datensatzes mit verknüpften Datensätzen einen Fehler provoziert, der durch das Ereignis Bei Fehler <\/b>des Hauptformulars abgefangen werden kann. Bevor wir einen Fehler abfangen und entsprechend behandeln können, brauchen wir allerdings zunächst seine Fehlernummer – immerhin liefert die Access-Meldung nur einen Fehlertext, aber keine Fehlermeldung.<\/p>\n Um die Fehlernummer zu erhalten, ergänzen wir der Ereignisprozedur, die durch das Ereignis Bei Fehler <\/b>ausgelöst wird, wie folgt:<\/p>\n Die beim anschließenden Versuch, einen Kunde samt Projekten zu löschen, liefert eine schlichte Meldung mit dem Inhalt 3200 <\/b>zu Tage.<\/p>\n Um herauszufinden, ob es sich hierbei um die richtige Fehlermeldung handelt, bemühen wir die Funktion AccessError<\/b>. Diese liefert, wie in Bild 5 gut zu erkennen, das erwartete Ergebnis.<\/p>\n Bild 5: Ermittlung des Fehlertextes zu einer Fehlernummer<\/span><\/b><\/p>\n Listing 3 zeigt schließlich die Prozedur, die beim Auftreten eines Formularfehlers ausgelöst wird und speziell den Fehler mit der Nummer 3200 behandelt.<\/p>\n Listing 3: Verknüpfte Datensätze löschen im Formularfehler-Ereignis<\/p>\n Da der Fehler in diesem Fall bereits aufgetreten und der Löschversuch somit schon gescheitert ist, müssen wir uns selbst um den Löschvorgang kümmern. Das gilt natürlich nur für den Fall, dass der Benutzer die Frage, ob er den Datensatz samt verknüpfter Daten löschen möchte, bejaht.<\/p>\n Wir verwenden dann erstens die Execute<\/b>-Methode des Database<\/b>-Objekts, um die verknüpften Datensätze zu löschen und anschließend die RunCommand<\/b>-Methode mit dem Parameter acCmdDeleteRecord<\/b>. Diese löscht einfach den aktuellen Datensatz im aktuellen Formular, was in diesem Fall das Hauptformular ist.<\/p>\n Listing 2: Störende verknüpfte Datensätze halbautomatisch mitentsorgen<\/p>\n Warum der Datensatz nicht auch per Execute<\/b>-Methode gelöscht wird Das ginge wohl, aber man soll möglichst nicht gleichzeitig über die Benutzeroberfläche (hier unserem Formular) und per Code auf die Daten der gleichen Datenherkunft zugreifen. Im vorliegenden Fall würde das zu dem Problem führen, dass der Datensatz nicht verschwindet, sondern als #Geloescht <\/b>angezeigt würde.<\/p>\n Wir löschen zwar die verknüpften Datensätze per Execute<\/b>-Anweisung gelöscht, was ebenfalls zu entsprechenden #Geloescht<\/b>-Ausdrücken im Unterformular führt, aber hier kein Problem ist, da der übergeordnete Datensatz ja auch noch gelöscht und anschließend ein anderer Datensatz angezeigt wird.<\/p>\n Grundsätzliche Vorgehensweise<\/b><\/p>\n Von diesem Beispiel können Sie mögliche Wege für andere Konstellationen ableiten. Wenn Sie – wie ich in einem aktuellen Projekt – Mitarbeiter zwar löschen können soll, wenn diese bereits die Benutzerumgebung angepasst haben, aber nicht mehr, wenn sie bereits selbst Kundendaten angelegt haben, dann müssen Sie in Abhängigkeit der Einstellungen bezüglich referentieller Integrität und Löschweitergabe prüfen, ob der Datensatz überhaupt gelöscht werden kann.<\/p>\n Danach geht es weiter, indem Sie die verknüpften und nicht mehr benötigten Daten ohne Rückfrage löschen und für sensiblere Daten gegebenenfalls den Benutzer fragen, ob dies in seinem Sinne ist.<\/p>\n Schließlich gibt es ja auch solche Restriktionen, die ein Löschen der Daten komplett untersagen.<\/p>\n Enthaltene Beispieldateien:<\/p>\n VerknuepfteDatenLoeschen.mdb<\/p>\n![\"pic002.png\"](\"..\/fileadmin\/_temp_\/2010_03\/VerknuepfteDatenLoeschen-web-images\/pic002.png\")
<\/p>\n![\"pic003.png\"](\"..\/fileadmin\/_temp_\/2010_03\/VerknuepfteDatenLoeschen-web-images\/pic003.png\")
<\/p>\n\n
![\"pic004.png\"](\"..\/fileadmin\/_temp_\/2010_03\/VerknuepfteDatenLoeschen-web-images\/pic004.png\")
<\/p>\n\n
Private Sub Form_Delete(Cancel As Integer)\r\n If DCount("ProjektID", "tblProjekte", _\r\n "KundeID = " & Me!KundeID) > 0 Then\r\n If MsgBox("Wenn Sie den Kunden löschen, werden auch die Projekte des Kunden gelöscht.\r\n Fortsetzen", vbOKCancel + vbExclamation, "Kunden löschen") = vbCancel Then\r\n Cancel = True\r\n End If\r\n End If\r\nEnd Sub<\/pre>\nPrivate Sub Form_Error(DataErr As Integer, _\r\n Response As Integer)\r\n MsgBox DataErr\r\nEnd Sub<\/pre>\n
![\"pic005.png\"](\"..\/fileadmin\/_temp_\/2010_03\/VerknuepfteDatenLoeschen-web-images\/pic005.png\")
<\/p>\nPrivate Sub Form_Delete(Cancel As Integer)\r\n Dim db As DAO.Database\r\n If DCount("ProjektID", "tblProjekte", "KundeID = " & Me!KundeID) > 0 Then\r\n If MsgBox("Wenn Sie den Kunden löschen, werden auch die Projekte des Kunden gelöscht.\r\n Fortsetzen", vbOKCancel + vbExclamation, "Kunden löschen") = vbOK Then\r\n Set db = CurrentDb\r\n db.Execute "DELETE FROM tblProjekte WHERE KundeID = " & Me!KundeID, dbFailOnError\r\n Else\r\n Cancel = True\r\n End If\r\n End If\r\nEnd Sub<\/pre>\nPrivate Sub Form_Error(DataErr As Integer, Response As Integer)\r\n Dim db As DAO.Database\r\n Select Case DataErr\r\n Case 3200\r\n If MsgBox("Wenn Sie den Kunden löschen, werden auch die Projekte des Kunden gelöscht.\r\n Fortsetzen", vbOKCancel + vbExclamation, "Kunden löschen") = vbOK Then\r\n Set db = CurrentDb\r\n db.Execute "DELETE FROM tblProjekte WHERE KundeID = " & Me!KundeID, dbFailOnError\r\n RunCommand acCmdDeleteRecord\r\n End If\r\n Response = acDataErrContinue\r\n End Select\r\nEnd Sub<\/pre>\nDownloads zu diesem Beitrag<\/h3>\n