Anmeldung an SQL Server und Co.

Wenn Sie ein aktives Datenbanksystem wie SQL Server oder MySQL als Backend Ihrer Access-Anwendung verwenden, müssen Sie sich vor dem Zugriff auf die Daten anmelden. Dieser Beitrag liefert Methoden, mit denen sich die Benutzer Ihrer Datenbanken auf verschiedenste Weise an unterschiedlichen Datenbanksystemen anmelden können – egal, ob Sie die Verbindungsdaten in einer DSN oder in der Datenbank speichern und ob Benutzername und/oder Kennwort in der Verbindungszeichenfolge stecken oder per Login-Dialog eingegeben werden sollen.

Sie verwenden eine Access-Anwendung zum Zugriff auf eine Datenbank in einem aktiven Datenbanksystem Dann kennen Sie sicherlich auch die erforderlichen Umstellungsarbeiten, wenn der Datenbankserver oder anderes geändert werden muss. Falls die ODBC-Verbindungsdaten als DSN-Datenquelle vorliegen, müssen Sie dafür sorgen, dass diese bei allen Clients aktualisiert werden. Nutzen Sie jedoch eine Verbindung ohne DSN (“DSN less”), reicht ein Update des Frontends aus.

Falls Sie mehrere unterschiedliche Datenbankmanagementsysteme (DBMS) nutzen, bleibt es meist nicht nur bei der änderung einiger Parameter, sondern der Connectionstring muss vollkommen neu gestaltet werden. Wäre es in diesem Fall nicht praktisch, wenn Sie nur ein Formular zum Einstellen der Verbindungsparameter öffnen müssten und der Rest von der Anwendung erledigt wird

Ziel

Der Anmeldevorgang an ein DBMS, also eine Datenbank mit einem SQL-Server-Backend, soll standardisiert werden, um unabhängig vom eingesetzten Server eine modularisierte Anmelderoutine nutzen zu können.

Ausgangssituation

In einer Access-Anwendung werden per ODBC verknüpfte Tabellen eingesetzt. Beim Verknüpfen der Tabellen können Sie entscheiden, ob das Passwort in der Verknüpfung gespeichert werden soll. Sobald Sie das Passwort speichern, ist ein Zugriff auf diese Tabellen ohne Anmeldung am DBMS möglich. Diese Variante kann eine Sicherheitslücke darstellen, da die Tabellen in eine ungeschützte .mdb-Datei importiert werden können. Aus diesem Grund ist es sinnvoll, das Passwort nicht zu speichern.

Dann erscheint beim erstmaligen Zugriff auf eine dieser Tabellen der ODBC-Anmelde-Dialog, wenn keine Windows-Authentifizierung genutzt wird. Damit Sie diesen Dialog umgehen beziehungsweise bei fehlgeschlagener Anmeldung die Access-Anwendung beenden können, ist es zweckmäßig, eine Anmelderoutine zu entwerfen, welche die Anmeldung am DBMS durchführt und vom Benutzer nur die Eingabe von Benutzername und Passwort fordert (s. Abb. 1).

APP_Anwendungsstart.png

Abb. 1: Anmeldedialog

Die Auswahl der Datenbank und des Servers ist für den Anwendungs-Benutzer eher nebensächlich, da dies meistens von den Anwendungsadministratoren vorab eingestellt wird. Das nachfolgende umgesetzte Konzept entspricht folgenden Anforderungen:

  • Unabhängig vom eingesetzten DBMS
  • Verbindung ohne Code-änderung konfigurierbar
  • Modularer Aufbau für flexiblen Einbau in Access-Anwendungen

Der Lösungsansatz sieht folgendermaßen aus:

  • Verbindungsparameter in Tabelle speichern
  • Verbindungsspezifischen Code in einem Klassenmodul sammeln
  • Jede Abfrage von Verbindungsdaten erfolgt ausschließlich über diese Klasse

Funktionsweise

Die folgenden Ausführungen beziehen sich auf die den Beitrag begleitende Beispieldatenbank DBMSVerbindung.mdb. Abb. 2 stellt den Ablauf schematisch dar. Über das Startformular frmAppWatcher wird die Startprozedur StartApplication aufgerufen, welche die Verbindungsprüfung startet.

Funktionsweise.wmf

Abb. 2: Ablauf beim Verbinden mit dem SQL-Server

Nach dem Auslesen der Verbindungsparameter wird bei Bedarf ein Loginformular zur Eingabe von Benutzer und Kennwort aufgerufen. Nach Eingabe dieser Werte werden die ODBC- und OLEDB-Connectionstrings erstellt.

Verwendung finden diese später in unterschiedlichsten Situationen: Beim Einbinden von ODBC-Tabellen, beim Erstellen von DAO- und ADO-Recordsets sowie beim Modifizieren von PassThrough-Abfragen.

Als nächster Schritt folgt nun der Verbindungstest. Wenn eine Verbindung aufgebaut werden konnte, wird das Loginformular geschlossen und eine ODBC-Verbindung zur Datenbank geöffnet. Anschließend wird in der Startprozedur mit der restlichen Anwendungsinitialisierung fortgefahren.

Falls beim Verbindungstest keine Verbindung hergestellt werden konnte, kann der Benutzer die Logindaten ändern oder die Anmeldung abbrechen. Mit dem Abbruch der Anmeldung wird dann auch die Anwendung beendet.

Umsetzung

Auf den folgenden Seiten ist eine Umsetzungsvariante für die zuvor getroffenen Anforderungen beschrieben. Aufgrund des doch etwas umfangreicheren Codes in der Beispielanwendung werden in der folgenden Beschreibung nur Code-Auszüge gezeigt. Wenn Sie mehr Details zu den gezeigten Prozeduren benötigen, öffnen Sie einfach den Code in der Beispielanwendung.

Speichern der Verbindungsdaten

Als Datenspeicher für die Verbindungsparameter dient eine lokale Tabelle im Frontend (s. Abb. 3). Diese Verbindungsparameter werden mittels Code zum ODBC- und OLEDB-Connectionstring zusammengesetzt. Ein Vorteil der Aufteilung in mehrere Datenfelder ist die Möglichkeit, die Werte getrennt zu nutzen. Im Datenfeld dbmsUser wird etwa der zuletzt angemeldete Benutzer gespeichert, damit dieser Name beim nächsten Anwendungsstart als Vorschlagswert verwendet werden kann. Das Präfix usys im Tabellennamen ist hilfreich, damit diese Systemtabelle nicht mitten in den eigentlichen Nutztabellen für die Anwendung aufgelistet wird. (Objekte mit dem Präfix usys werden wie mit MSys ausgeblendet, wenn in den Access-Optionen die Einstellung Systemobjekte anzeigen nicht aktiviert ist.)

TAB_usys_DbmsConnection.png

Abb. 3: Die Tabelle usys_DbmsConnection

Das Formular frmConfig_DBMS und das Unterformular frmConfig_DBMS_SF_Data dienen zur Eingabe dieser Verbindungsdaten (s. Abb. 4). Je nach Auswahl der Verbindungsart ohne DSN, mit DSN beziehungsweise benutzerdefiniert werden die benötigten Eingabefelder aktiviert. In der Beispieldatenbank wird für diese Steuerung die Hilfstabelle usys_DbmsConnection_X genutzt, damit der Formularcode unabhängig vom eingesetzten DBMS ist.

FRM_frmConfig_DBMS.png

Abb. 4: Das Formular zum Konfigurieren der Verbindungen

Falls Sie nur ein einziges DBMS verwenden, könnten Sie auf diese Tabelle verzichten und stattdessen Konstanten im VBA-Code einsetzen. Die Aktivierung der Eingabefelder erfolgt in der Formularprozedur setLayoutMode (s. Listing 1).

Listing 1: Aktivierung der Eingabefelder

Private Sub setLayoutMode()
    ...
    lngConnectionMode = Nz(Me!dbmsConnectionMode, -1)
    ' dbmsConnectionMode ... Datenfeld aus usys_DbmsConnection
    ...
    Me.txtDbmsServer.Enabled = _
    ((Nz(Me!XdbmsServer, 255) And lngConnectionMode) = lngConnectionMode)
    ' txtDbmsServer ... Steuerelement im Formular
    ' XdbmsServer... Ja/Nein-Feld aus der Tabelle usys_DbmsConnection_X
    Me.txtDbmsPort.Enabled = _
    ((Nz(Me!XdbmsPort, 255) And lngConnectionMode) = lngConnectionMode)
    ...
    End Sub

Mit der Schaltfläche Verbindung testen (cmdCheckConnection) erfolgt der erste Einsatz der DbConnectionInfo-Klasse, die mit den angezeigten Daten den ODBC- und OLEDB-Connectionstring erzeugt sowie einen Verbindungstest durchführt (s. Listing 2).

Listing 2: Prüfen der Verbindung

Public Function CheckConnection(Optional ByRef errMsg As String = vbNullString) As Boolean
    Dim checkOk As Boolean
    On Error GoTo HandleErr
    checkOk = checkAdoConnection(OleDbConnectionstring, errMsg)
    If checkOk Then 'ODBC testen (außer ADO-Check schlug bereits fehl)
    checkOk = checkOdbcConnection(OdbcConnectionstring, errMsg)
End If
CheckConnection = checkOk
...
End Function

Wie dieser Verbindungsaufbau und der Verbindungstest abläuft, ist aus Sicht des Formulars nebensächlich (Stichwort: Kapselung). Für den Formularcode reicht es aus, wenn True beziehungsweise False zurückgeliefert wird. Im Falle eines negativen Verbindungstests ist es allerdings hilfreich, den Grund für den fehlgeschlagenen Verbindungsaufbau anzuzeigen.

Das ermöglicht das Auslesen des Wertes aus der Variablen errMsg, die als ByRef-Parameter an die Methode CheckConnection übergeben wurde. Nun ist es an der Zeit, die Klasse DbConnectionInfo genauer zu betrachten.

Die Klasse DbConnectionInfo

Die Klasse DbConnectionInfo ist die “Steuerzentrale” für die Bereitstellung der benötigten Verbindungsinformationen. Tab. 1, Tab. 2 und Tab. 3 zeigen die Eigenschaften, Methoden und Ereignisse dieser Klasse.

Eigenschaft

Beschreibung

Tab. 1: Eigenschaften der Klasse DBConnectionInfo

Methode

Beschreibung

Tab. 2: Methoden der Klasse DbConnectionInfo

Ereignis

Beschreibung

Tab. 3: Ereignisse der Klasse DbConnectionInfo

Sie haben das Ende des frei verfügbaren Textes erreicht. Möchten Sie ...

Workplace

Jahresabonnement TestzugangOder haben Sie bereits Zugangsdaten? Dann loggen Sie sich gleich hier ein:

Schreibe einen Kommentar