Zur Hauptseite ... Zum Onlinearchiv ... Zum Abonnement ... Zum Newsletter ... Zu den Tools ... Zum Impressum ... Zum Login ...

Achtung: Dies ist nicht der vollständige Artikel, sondern nur ein paar Seiten davon. Wenn Sie hier nicht erfahren, was Sie wissen möchten, finden Sie am Ende Informationen darüber, wie Sie den ganzen Artikel lesen können.

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

Gedrucktes Heft

Diesen Beitrag finden Sie in Ausgabe 3/2009.

Unser Angebot für Sie!

Lesen Sie diesen Beitrag und 500 andere sofort im Onlinearchiv, und erhalten Sie alle zwei Monate brandheißes Access-Know-how auf 72 gedruckten Seiten! Plus attraktive Präsente, zum Beispiel das bald erscheinende Buch 'Access 2010 - Das Grundlagenbuch für Entwickler'!

Diesen Beitrag twittern

Zusammenfassung

Bekommen Sie die Verknüpfungen zu MySQL, SQL Server und Co. ganz einfach in den Griff.

Techniken

Tabellenverknüpfungen, ODBC

Voraussetzungen

Access 2000

Beispieldateien

DbmsVerbindung.mdb

Shortlink

668

Anmeldung an SQL Server und Co.

Josef Pötzl, Graz

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

CID

Verbindungskennung

DbmsName

DBMS-Kennung

DbName

Datenbankname

DbServer

Datenbankserver

DbUser

Benutzer

DbUserPassword

Passwort

LoginForm

Referenz zum Login-Formular

ConnectionStrings

Type DbmsConnectionStrings (ODBC+OLEDB)

OdbcConnectionstring

ODBC-Connectionstring

OleDbConnectionstring

OLEDB-Connectionstring

PermanentBackendRstSqlText

SQL-Anweisung des Hilfsrecordsets zum Offenhalten der ODBC-Verbindung

SavePassword

Wird zum Verknüpfen von Tabellen benötigt

TableListSqlText

SQL-Anweisung zum Auflisten von Tabellen im jeweiligen DBMS

UseLoginForm

Wert aus usys_DbmsConnection

Tab. 1: Eigenschaften der Klasse DBConnectionInfo

Methode

Beschreibung

ChangeDbUserPassword

Passwort ändern

CheckConnection

Verbindung zum Server bzw. zur Datenbank prüfen

ClearConnectionInfo

Alle eingelesenen Daten in der Klasse leeren

Tab. 2: Methoden der Klasse DbConnectionInfo

Ereignis

Beschreibung

DbmsConnectionChanged

Meldet Änderung der Verbindung

DbmsInfoMessage

Unterstützt Meldungsanzeige

PasswordChanged

Meldet Passwortänderung

Disposed

Wird ausgelöst, wenn Instanz zerstört wird

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).

Sie haben das Ende des frei verfügbaren Teils des Artikels erreicht. Lesen Sie weiter, um zu erfahren, wie Sie den vollständigen Artikel lesen und auf viele hundert weitere Artikel zugreifen können.

Sind Sie Abonnent?Jetzt einloggen ...
 

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

Verwandte Beiträge:

DBMS-unabhängiger Zugriff auf SQL Server und Co.

Der DBMS-Connection-Wizard

Performanter Webzugriff auf MySQL-Datenbanken

Access, MySQL und Berechtigungsverwaltung

Upsizing von Access nach SQL Server: Tabellen

Gespeicherte Prozeduren

Benutzerdefinierte Funktionen im MS SQL Server

Von Access nach MySQL, Teil 2

Access, MySQL und Datenzugriff

Trigger

Datensicherung mit dem MS SQL Server

Abfragen von Access zum SQL Server

Verschlüsselung und Komprimieren im Backend

Ereignisprozeduren implantieren

Die Microsoft Data Engine (MSDE)

Von Access nach MySQL

© 2003-2015 André Minhorst Alle Rechte vorbehalten.