Wer seine Access-Tabellen von einem Access-Backend in ein SQL Server-Backend übertragen hat, dürfte zunächst keinen Unterschied beim Zugriff auf die Daten bemerken. Spannend wird es, wenn Sie unter Access jedoch die sogenannten Datenmakros verwendet haben, um automatisch auf Änderungen in den Daten zu reagieren und beispielsweise Kopien geänderter oder gelöschter Datensätze in einer Archivtabelle angelegt haben. Beim Migrieren nach SQL Server werden zwar auch die Archivtabellen erstellt, aber die Datenmakros bleiben außen vor. Damit keine Daten verloren gehen, zeigen wir in diesem Beitrag, wie Sie die Tabellen mit Triggern ausstatten, um die gewünschten Daten zu archivieren.
Voraussetzungen
Für den Zugriff auf den SQL Server und speziell für das Ändern des Datenmodells, zu dem auch die Trigger gehören, kann man das SQL Server Management Studio verwenden. Wir nutzen zwar gern die Tools, die wir im Beitrag SQL Server-Tools vorgestellt haben (siehe www.access-im-unternehmen.de/1061) – aber im Rahmen des vorliegenden Beitrags wollen wir die Aufgabe zunächst im SQL Server Management Studio erledigen. Später erfahren Sie, wie wir dann doch noch unsere Tools zum Anlegen von Triggern und Archivtabellen nutzen können.
Ziel des Beitrags
Das Ziel ist, für die Tabellen, für die es notwendig ist, Trigger zu definieren, die beim Löschen oder Ändern von Datensätzen einer Tabelle die zuletzt verwendete Version des jeweiligen Datensatzes zu archivieren. Wenn Sie also einen Datensatz löschen, soll dieser vor dem Löschen in eine als Archivtabelle angelegte Kopie der Tabelle mit dem Originaldatensatz kopiert werden. Wenn ein Datensatz geändert wird, soll ebenfalls eine Kopie des Originaldatensatzes in der Archivtabelle gespeichert werden.
In beiden Fällen stellt sich die Frage: Welche Daten speichern wir zusätzlich zu den zu archivierenden Daten in der Archivtabelle und wie sieht diese dann aus Wir wollen die Kopien geänderter Datensätze auf jeden Fall den neuen Versionen der Datensätze zuordnen können. Daher sollte die Tabelle mit den archivierten Datensätzen ein Feld zum Aufnehmen des Primärschlüsselwertes des Originaldatensatzes enthalten. Außerdem wollen wir noch speichern, wann der Datensatz geändert oder gelöscht wurde und natürlich, ob er nun geändert oder gelöscht wurde. Da es mehrere Versionen des gleichen Datensatzes in der Archivtabelle geben kann, können wir also nicht das Primärschlüsselwert des Originaldatensatzes als Primärschlüsselwert des archivierten Datensatzes verwenden, sondern müssen für die Archivtabelle ein eigenes Primärschlüsselfeld vorsehen.
Wir benötigen also alle Felder der Originaltabelle, ein neues Primärschlüsselfeld sowie jeweils ein Feld für die Angabe des Datums und eines für die Aktion, welche für das Archivieren des Datensatzes verantwortlich ist – also Löschen oder Bearbeiten.
Das Primärschlüsselfeld wollen wir immer ArchivID nennen und die beiden anderen Felder sollen Archivdatum und Archivart heißen.
Aber ist das die beste Lösung Wir können alternativ auch zwei Felder hinzufügen, die Loeschdatum und Aenderungsdatum heißen und je nach Vorgang das eine oder andere Feld füllen. Wir entscheiden uns für die zuletzt vorgeschlagene Variante und wollen diese beiden Felder zu den Archivtabellen hinzufügen. Die Archivtabellen müssen wir natürlich auch noch entsprechend benennen. In diesem Fall wollen wir einfach den Namen der zu archivierenden Tabelle nutzen und dieser das Suffix _Archiv anhängen. Für die Tabelle tblKunden entsteht so beispielsweise die Tabelle tblKunden_Archiv.
Archivtabelle im SQL Server Management Studio anlegen
In Visual Studio legen wir die gewünschte Tabelle am schnellsten wie folgt an:
- Öffnen Sie SQL Server Management Studio.
- Navigieren Sie zu der gewünschten Tabelle in der entsprechenden Datenbank.
- Wählen Sie für die Tabelle den Kontextmenü-Eintrag Skript für Tabelle als|CREATE in|Neues Abfrage-Editor-Fenster aus (siehe Bild 1).
Bild 1: Archivtabelle anlegen
Daraufhin erscheint ein neues Abfragefenster, das den SQL-Code zum Erstellen der Tabelle anzeigt, hier tblKunden. Hier nehmen Sie einige Änderungen vor. Die erste ist, dass wir den Tabellennamen in tblKunden_Archiv ändern. Danach fügen wir das Feld ArchivID als neuen Primärschlüsselwert hinzu und gestalten das Feld KundeID als normales Integer-Feld. Außerdem legen wir am Ende noch die beiden Felder Loeschdatum und Aenderungsdatum an, jeweils mit dem Datentyp DATETIME. Außerdem ändern wir noch den Namen des Primärschlüsselfeldes für den CONSTRAINT-Abschnitt. Der SQL-Code sieht dann in gekürzter Form wie folgt aus:
CREATE TABLE [dbo].[tblKunden_Archiv]( [ArchivID] [int] IDENTITY(1,1) NOT NULL, [KundeID] [int] NULL, [KundenCode] [nvarchar](5) NULL, [Firma] [nvarchar](40) NOT NULL, [AnredeID] [int] NULL, [Vorname] [nvarchar](255) NULL, [Nachname] [nvarchar](255) NULL, [Position] [nvarchar](30) NULL, [PLZ] [nvarchar](10) NULL, [Strasse] [nvarchar](255) NULL, [Ort] [nvarchar](15) NULL, [Region] [nvarchar](15) NULL, [Land] [nvarchar](15) NULL, [Telefon] [nvarchar](24) NULL, [Telefax] [nvarchar](24) NULL, [Loeschdatum] [datetime] NULL, [Aenderungsdatum] [datetime] NULL CONSTRAINT [tblKunden_Archiv$PrimaryKey] PRIMARY KEY CLUSTERED ( [ArchivID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY]
Nur diesen Teil wollen wir dann auch ausführen. Löschen Sie also den Rest des automatisch erzeugten Skriptes oder markieren Sie nur diesen Teil und führen Sie diesen mit F5 aus.
Nach einer Aktualisierung des Knotens Tabellen im SQL Server Management Studio erscheint die Tabelle tblKunden_Archiv dann in der Liste der Tabellen und der Entwurf sieht wie in Bild 2 aus.
Bild 2: Entwurf der neuen Archivtabelle
Trigger im SQL Server Management Studio anlegen
Nun wollen wir die notwendigen Trigger für die Tabelle tblKunden anlegen, die dafür sorgen, dass ein zu löschender oder zu ändernder Datensatz vor dem jeweiligen Vorgang in die Tabelle tblKunden_Archiv gesichert wird. Wenn man das Kontextmenü der Tabelle tblKunden durchsieht, findet man dort keine Möglichkeit, einen Trigger anzulegen. Allerdings gibt es unterhalb des Elements tblKunden ein weiteres Element namens Trigger, dessen Kontextmenü den Eintrag Neuer Trigger… liefert (siehe Bild 3).
Bild 3: Anlegen eines neuen Triggers
Trigger beim Aktualisieren
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
den kompletten Artikel im PDF-Format mit Beispieldatenbank
diesen und alle anderen Artikel mit dem Jahresabo