Kategorie: SQL Server und Co.

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.

Wenn Sie die Daten Ihrer Access-Datenbank über das Internet für verschiedene Access-Frontends verfügbar machen wollen, müssen Sie zwei Schritte erledigen: Der erste ist die Migration der Tabellen in eine SQL Server-Datenbank, der zweite die Bereitstellung dieser Datenbank über das Internet. Letzteres gelingt mit den Azure-Diensten von Microsoft. Wie das funktioniert, zeigt der vorliegende Beitrag im Detail.

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.

Es gibt verschiedene Möglichkeiten, auf die Daten einer SQL Server-Datenbank zuzugreifen. Die einfachste Variante, gerade wenn es um die Migration einer reinen Access-Datenbank in eine Kombination aus Access-Frontend und SQL Server-Backend geht, ist der Einsatz von per ODBC verknüpften Tabellen. Dabei werden die Tabellen einfach nur zum SQL Server migriert und man greift dann über ODBC-Verknüpfungen auf die Tabellen zu. Für den Zugriff auf diese Daten von Formularen aus ergeben sich so gut wie keine Änderungen – und was sich doch ändern kann, erfahren Sie in diesem Beitrag.

Wenn Sie mit dem Microsoft SQL Server arbeiten und SQL Server-Instanzen, die enthaltenen Datenbanken mit Tabellen und weiteren Objekten, Sicherheitselemente wie Anmeldungen, Benutzer oder Benutzergruppen und mehr verwalten wollen, kommen Sie um das SQL Server Management Studio nicht herum. Sie können zwar theoretisch alle Aktionen, die Sie mit diesem Tool durchführen, auch mit T-SQL direkt aufrufen. Aber dafür müssen Sie schon profunde Kenntnisse dieser Sprache in Zusammenhang mit der Verwaltung einer SQL Server-Instanz haben. Dieser Beitrag liefert die Grundlagen für den Umgang mit dem Administrationstool für den SQL Server.

Für die Beispiele der Beiträge in diesem Heft und in weiteren Ausgaben wollen wir mit Beispieldatenbanken arbeiten, die wir nicht immer komplett neu erstellen, sondern aus einer von mehreren Quellen auf dem Rechner, auf dem Sie die Beispiele ausprobieren, wiederherstellen wollen. Dazu gibt es drei gängige Methoden, die wir in diesem Artikel vorstellen wollen: den Assistenten zum Kopieren von Datenbanken, das Wiederherstellen einer Datenbanksicherung sowie das Wiederherstellen mithilfe eines Skripts. Wir wollen einen Blick auf die letzteren beiden Varianten werfen.

Der Wechsel von einem Access-Backend zum SQL Server als Backend-System hat – neben der Performance und dem Speicherplatz – oft einen entscheidenden Grund: Access schützt die Daten nicht ausreichend vor fremden Zugriffen. Hier hat der SQL Server deutlich die Nase vorn, denn er bietet verschiedene Möglichkeiten der Sicherung der Daten vor dem unbefugten Zugriff. Dieser Artikel zeigt, wie das Sicherheitssystem und die Benutzerverwaltung im SQL Server funktionieren.

Im Beitrag „SQL Server: Sicherheit und Benutzerverwaltung“ haben wir gezeigt, wie Sie grundsätzlich mit Benutzern, Benutzergruppen und den Berechtigungen an den einzelnen Elementen einer SQL Server-Datenbank umd dem SQL Server selbst umgehen. Dort sind wir allerdings nur auf den Zugriff per Windows-Authentifizierung eingegangen. Viele Szenarios erfordern es allerdings, dass Sie die SQL Server-Authentifizierung verwenden, was bedeutet, dass Sie unter dem SQL Server eigene Konten für Benutzergruppen und Benutzer anlegen – unabhängig von den Windows-Benutzergruppen und -Benutzern. Dieser Beitrag liefert die Grundlagen rund um die Verwendung der SQL Server-Authentifizierung.

Wenn Sie per ODBC auf die Tabellen etwa eines SQL Servers zugreifen, kennen Sie das Dilemma: Entweder Sie nutzen die Windows-Authentifizierung, was nicht überall möglich ist, aber ohne größere Probleme funktioniert. Oder Sie verwenden die SQL Server-Authentifizierung. Dann haben Sie zwei Möglichkeiten: Entweder Sie erlauben das Speichern des Kennworts in den Systemtabellen von Access. Oder der Benutzer muss nach dem eigentlichen Anmelden nochmal seine Benutzerdaten eingeben, wenn der erste Zugriff auf eine Tabelle erfolgt. In dieser Lösung schauen wir uns diese Varianten an – und eine bessere, bei der Sie einfach die Tabellen beim Start neu verknüpfen.