Lies diesen Artikel und viele weitere mit einem kostenlosen, einwöchigen Testzugang.
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 (siehe Bild 1).
Bild 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.
Bild 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 (siehe Bild 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.)
Bild 3: Die Tabelle usys_DbmsConnection
Das Formular frmConfig_DBMS und das Unterformular frmConfig_DBMS_SF_Data dienen zur Eingabe dieser Verbindungsdaten (siehe Bild 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.
Bild 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
Wie diese Klasse aufgebaut ist, sehen Sie am besten, wenn Sie die Entstehung der Eigenschaften, Methoden und Ereignisse nach deren „Bedarfszeitpunkt“ betrachten.
Die zuerst benötigte Methode war CheckConnection für die Überprüfung der Verbindungsparameter im Formular frmConfig_DBMS_SF_Data (s. Listing 3). Damit der Code übersichtlich bleibt, werden die Prüfungen für die OLEDB- und ODBC-Verbindung in Hilfsprozeduren ausgelagert. Innerhalb der beiden Hilfsprozeduren wird versucht, mit dem übergebenen Connectionstring eine Verbindung aufzubauen, und bei Erfolg wird True zurückgegeben. An diese Hilfsprozeduren werden der OLEDB- beziehungsweise ODBC-Connectionstring übergeben (s. Listing 3 und Listing 4).
Listing 3: Die Routine CheckConnection
Private Sub cmdCheckConnection_Click()
Dim strCID As String
Dim oDbConnectionInfo As DbConnectionInfo
Dim errMsg As String
On Error GoTo HandleErr
If Me.Dirty Then Me.Dirty = False
strCID = Nz(Me!CID, vbNullString)
If Len(strCID) = 0 Then Exit Sub
Set oDbConnectionInfo = New DbConnectionInfo
oDbConnectionInfo.CID = strCID ' Übergabe der Verbindungskennung
If oDbConnectionInfo.CheckConnection(errMsg) = True Then
MsgBox "Verbindungsaufbau war erfolgreich"
Else
If Len(errMsg) > 0 Then errMsg = vbNewLine & vbNewLine _
& errMsg
MsgBox "Verbindung konnte nicht hergestellt werden." _
& errMsg
End If
Set oDbConnectionInfo = Nothing
...
End Sub
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
Testzugang
eine Woche kostenlosen Zugriff auf diesen und mehr als 1.000 weitere Artikel
diesen und alle anderen Artikel mit dem Jahresabo