Kategorie: SQL Server und Co.

Wenn Sie die Tabellen einer Microsoft Access-Datenbank in eine MySQL-Datenbank migrieren wollen, haben Sie verschiedene Möglichkeiten. Sie können das von Hand erledigen, was eine Menge Arbeit ist, oder ein Tool zur mehr oder weniger automatischen Migration nutzen. MySQL selbst bietet dazu den MySQL Workbench Migration Wizard an, den wir uns in diesem Beitrag anschauen.

Wenn Sie eine Datenbank von mehreren Standorten aus nutzen, aber nicht auf den Komfort der Access-Programmierung verzichten wollen, dann gibt es nicht viele Möglichkeiten. Sie können entweder eine SQL Server-Datenbank oder eine MySQL-Datenbank auf einem Internetserver ablegen und für den Zugriff von einer Access-Datenbank aus verfügbar machen. Wie das gelingt, haben wir am Beispiel von MySQL in verschiedenen Beiträgen bereits dargestellt. Der vorliegende Beitrag schließt den Kreis und zeigt, wie Sie von einem Access-Frontend aus auf die MySQL-Datenbank auf dem Internetserver zugreifen und mit den Daten so arbeiten, als würden diese auf dem heimischen Rechner liegen. Wir starten mit einigen Tools, die den Zugriff erleichtern.

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.

Im Beitrag „Datenhistorie per Trigger“ haben wir gezeigt, welche Anweisungen nötig sind, um eine Archivtabelle anzulegen und der Originaltabelle einen Trigger hinzuzufügen, der beim Ändern oder Löschen eines Datensatzes die vorherige Version in einer Archivtabelle speichert. Im vorliegenden Beitrag wollen wir eine VBA-Prozedur entwickeln, mit der Sie zu einer Tabelle mit einem einfachen Aufruf die Archivtabelle und den Trigger in einem Rutsch anlegen können. Damit sichern Sie Ihre Daten bei Änderungen auch für mehrere Tabellen ganz schnell ab.

Im Beitrag „Kopier- und Löschreihenfolge für Tabellen“ (www.access-im-unternehmen.de/926) haben wir ermittelt, wie wir die richtige Reihenfolge für das Löschen von Tabellen und das Kopieren von Tabelleninhalten von einer Datenbank in die nächste ermitteln. Wenn Sie die Reihenfolge nicht beachten, kann es nämlich sein, dass Datensätze wegen Fremdschlüsselverletzungen nicht gelöscht und auch nicht kopiert werden können. Im vorliegenden Beitrag zeigen wir, wie Sie die vorgestellte Lösung für das Löschen und Kopieren von Tabellen in MySQL-Datenbanken nutzen können.

Im Beitrag „Berechtigungen für Access-Objekte per SQL Server I: Tabellen“ haben wir ein Datenmodell entwickelt für die Verwaltung der Berechtigungen verschiedener Benutzergruppen auf die Formulare, Berichte und Steuer-elemente einer Access-Anwendung – gesteuert über die jeweilige Anmeldung an der SQL Server-Datenbank. Im zweiten Teil dieser Beitragsreihe haben wir das Formular zum Einstellen der Berechtigungen erstellt. Im dritten Teil zeigen wir nun, wie wir die gespeicherten Berechtigungen nutzen, um Formulare und Steuer-elemente vor dem unbefugten Zugriff zu schützen.

Im Beitrag „Berechtigungen für Access-Objekte per SQL Server I: Tabellen“ haben wir ein Datenmodell entwickelt für die Verwaltung der Berechtigungen verschiedener Benutzergruppen auf die Formulare, Berichte und Steuer-elemente einer Access-Anwendung – gesteuert über die jeweilige Anmeldung an der SQL Server-Datenbank. Im zweiten Teil dieser Beitragsreihe verknüpfen wir die Access-Anwendung mit diesen Tabellen und erstellen die Formulare, die zur Bearbeitung der für die Berechtigungsverwaltung notwendigen Tabellen erforderlich sind.

Die älteren SQL Server-Versionen haben einen Nachteil: Sie benötigen hier einen Benutzer, dem eine neu erstellte Datenbank gehört. Genauso gibt es auch für alle weiteren Objekte wie Tabellen, Sichten, gespeicherte Prozeduren und so weiter einen Besitzer – nämlich den Benutzer, der das Objekt erstellt hat. Meist legt man diese Elemente im Kontext eines Windows-Benutzers an, was zum Beispiel dazu führt, dass Sie diesen Benutzer nicht einfach löschen können, ohne zuvor alle Elemente dieses Benutzers an einen anderen Benutzer übertragen zu haben. Aus diesem Grund hat Microsoft mit SQL Server 2005 den Typ namens „Schema“ eingeführt. Diesem werden nun nicht nur neu erstellte Objekte zugeordnet, sondern Sie können auch mehrere Schemas pro Datenbank verwenden, um beispielsweise Elemente nach verschiedenen Gruppen zu sortieren.

Im Beitrag „SQL Server: Sicherheit und Benutzerverwaltung“ haben wir gezeigt, wie Sie die Sicherheitsfunktionen für den Zugriff auf SQL Server und SQL Server-Datenbanken für Benutzergruppen und Benutzer einrichten. Damit ist der Zugriff auf die Elemente des SQL Servers geregelt. Was aber ist mit den Objekten im Access-Frontend – also beispielsweise mit Formularen, Schaltflächen, Ribbon-Einträgen und so weiter Wenn wir schon Benutzer und Benutzergruppen im SQL Server einrichten, möchten wir diese ja auch nutzen, um die Elemente der Benutzeroberfläche je nach der Anmeldung für Benutzergruppe oder Benutzer freizugeben oder auch nicht. Ein Beispiel dafür, wie Sie dies realisieren können, liefert der vorliegende Beitrag. In diesem ersten Teil erstellen wir das Datenmodell für die Berechtigungsverwaltung.

Unter Access sind Sie es gewohnt, nach Lust und Laune am Entwurf einer Tabelle zu arbeiten. Probleme gibt es nur, wenn Sie einmal die Feldgröße oder den Felddatentyp ändern wollen – etwa, weil die Daten dann nicht mehr in das Feld passen könnten. Das können Sie jedoch durch einen Mausklick bestätigen und weitermachen. Beim SQL Server sieht das etwas anders aus. Relevante Änderungen, die sich auf bestehende Felder beziehen, sieht das SQL Server Management Studio nicht so gern und blockiert dies – Sie müssen dann die Tabelle neu anlegen. Wer einen kleinen Trick nicht kennt, macht sich auf diese Weise viel unnötige Arbeit.