Zugriff auf Server über ODBC, Teil II

Lies diesen Artikel und viele weitere mit einem kostenlosen, einwöchigen Testzugang.

Das manuelle Verknüpfen einer SQL-Server-Tabelle in eine Access-Datenbank über den ODBC-Administrator von Windows ist die eine Sache, das programmgesteuerte Beleben der Verbindung und das Neuverknüpfen über VBA eine andere! Zeigte die Juli-Ausgabe von ACCESS BASICS die Grundlagen zum Umgang mit ODBC-Backends, so erfahren Sie hier mehr über die Ansprache von ODBC-Verbindungen durch VBA-Programmierung.

Beispieldatenbank

Die Beispiele dieses Artikels finden Sie in der Datenbank 1608_ODBC2.zip.

ODBC-Tabellen neu verknüpfen

Die Aufteilung einer Datenbank in Logik und Daten kennen Sie bereits von reinen Access-Datenbanken: Das Frontend enthält nur die Oberfläche, also Formulare und Berichte, sowie den VBA-Code, und außerdem Abfragen. Das Backend ist eine separate Access-Datei, welche ausschließlich Tabellen beherbergt, welche in das Frontend verknüpft werden. Ebenso verhält es sich mit dem Gespann Access und SQL-Server, nur dass sich hier die Daten aus einem DBMS-Server speisen und die Tabellen über ODBC-Verknüpfungen in das Frontend gelangen.

Beim Verschieben eines Access-Backends etwa auf eine andere Maschine stimmen dann die Tabellenverknüpfung nicht mehr und müssen beim Start des Frontends angepasst werden, da Access in der Verknüpfung grundsätzlich absolute statische Pfade abspeichert. ähnlich sieht es bei ODBC-Verknüpfungen aus. Der Ort des SQL-Servers oder der Tabellen auf ihm kann sich ändern, was eine Anpassung der Verknüpfungen im Frontend nach sich ziehen muss.

Egal, ob beim Access- oder ODBC-Backend, das Neuverknüpfen der Tabellen sollte ein Vorgang sein, der weitgehend automatisiert und möglichst ohne manuelle Interaktion vonstattengeht. Hier kommen Sie um VBA-Routinen nicht herum, die Sie etwa in Ausgabe 06/2011 Tabellenverknüpfungen pflegen finden.

Bei ODBC-Verknüpfungen verwenden Sie Code, der ganz ähnlich gestaltet ist. Eine Tabelle wird über ein DAO-TableDef-Objekt repräsentiert und dessen Eigenschaft Connect enthält die relevanten Informationen zum Backend-Ort. Verwenden Sie etwa diese VBA-Zeilen, um die Connect-Eigenschaft für die Tabelle tblAdressen auszulesen:

Set dbs = CurrentDb
 dbs.TableDefs("tblAdressen").Connect

Befände sich die Tabelle in einem Access-Backend, dann könnte das Ergebnis so aussehen:

;DATABASE=c:\users\fritz\test.accdb

Das erste Zeichen des Connect-Strings ist ein Semikolon, was darauf hinweist, dass vor ihm noch Anderes stehen könnte. Der Leer-String aber sagt Access, dass es sich hier um eine Access-Datei handeln muss, deren Pfad schließlich im Parameter DATABASE folgt.

Greift die Verknüpfung hingegen auf eine ODBC-Tabelle zu, so sieht das Ergebnis anders aus:

ODBC;DSN=Access Basics Demo;Driver={SQLite3 ODBC Driver};Database=c:\users\fritz\adressen.sqlite;FKSupport=1; usw...

Hier steht an erster Stelle der Ausdruck ODBC, was Access darauf hinweist, die Tabelle über einen ODBC-Treiber zu finden. Die weiteren Angaben hierzu folgen im Anschluss.

Die eine Möglichkeit besteht dabei im Zugriff auf eine DSN, wie sie im ersten Teil des Beitrags manuell über den ODBC-Administrator angelegt wurde. Hinter dem Parameternamen DSN folgt dann der Name der angelegten DSN – hier: Access Basics Demo. Das würde an sich bereits ausreichen, denn in der Benutzer-DSN, welche ihrerseits alle Informationen in der Registry ablegt, stehen schon alle Angaben zu Treiber, Datenbankort und Zugriffsoptionen.

Die Alternative wäre der Verzicht auf eine zuvor angelegte DSN. Dann entfällt der DSN-Parameter im Connect-String und alle Angaben zur ODBC-Verbindung müssen stattdessen in ihm angegeben werden. Das wäre der Teil ab Driver…:

ODBC;Driver={SQLite3 ODBC Driver}; Database=c:\users\fritz\adressen.sqlite; FKSupport=1;...usw.

Die aufeinanderfolgenden Parameternamen, wie Database, FKSupport, et cetera, sind keine, die Access selbst kennt! Sie unterscheiden sich je nach gewähltem ODBC-Treiber, der sie seinerseits kennt. Nur der SQLite-Treiber etwa weiß, dass Database der Ort der SQLite-Datei ist, die er laden soll, und dass FKSupport die Option zur Unterstützung von Fremdschlüsseln ist.

Wie kommen Sie an diese Parameternamen und deren Bedeutung Hier bleibt Ihnen nur die Dokumentation zum Treiber auf dessen Herstellerseite oder die Recherche etwa auf connectionstrings.com, einer Seite, die zu allen gängigen DBMS die ODBC-Connect-Strings mehr oder weniger kommentiert auflistet.

Stimmen Parameternamen oder -werte nicht, so ignorieren ODBC-Treiber diese in der Regel. Soweit möglich, kommt dennoch eine Verbindung zustande und der Treiber setzt Default-Werte ein.

Fehlen relevante Angaben, so öffnet sich der jeweilige Treiber-Dialog des ODBC-Administrators und verlangt nach manueller Eingabe. Unter Umständen meldet Access aber auch einfach: Kann keine ODBC-Verbindung herstellen, oder ähnlich.

Im Falle des SQLite-Treibers und dem nebenstehenden Connect-String kommt es zur Fehlermeldung -7778 mit dem Text: Reservierter Fehler; es gibt keine Beschreibung für diesen Fehler. Microsoft macht wenig erhellende Angaben zu diesem Fehler. Er kann verschiedene Ursachen haben, die in Authentifizierungsproblemen begründet scheinen. Wie auch immer, ohne Angabe einer DSN funktioniert ein SQLite-Connect-String nicht.

Glücklicherweise legt der ODBC-Treiber für SQLite bei Installation automatisch eine System-DSN an, die immer den Namen SQLIte3 Datasource aufweist. Diese DSN enthält lediglich Angaben zum Treiber, nicht aber zum Ort einer SQLite-Datenbankdatei. Tatsächlich kann man nun im Connect-String beides kombinieren: den DSN-Namen und die Optionsparameter im Anschluss! Demgemäß hat der Connect-String für SQLite immer diesen Anfang:

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