ADODB als Alternative zu DAO

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

Der Umgang mit Daten unter VBA findet in der Regel über die Bibliothek DAO statt, welche Access über den gleichnamigen Verweis beim Erzeugen einer neuen Datenbank automatisch in das VBA-Projekt einbindet. Microsoft hat sie damit zum Standard erkoren. Tatsächlich gibt es aber noch ein anderes Schwergewicht für den Datenzugriff, das unter dem Kürzel ADODB daherkommt. Führen wir uns diese Bibliothek einmal als Alternative zu DAO zu Gemüte.

Beispieldatenbank

Die Beispiele dieses Artikels finden Sie in der Datenbank 1508_ADO.zip.

Datenzugriffsbibliotheken

Die Zeiten ändern sich. War DAO (Data Access Objects) als Schnittstelle zu den Datenobjekten unter VBA mit dem Erscheinen von Access noch die einzige Bibliothek, so führte Microsoft mit Office 2000 eine neue ein, die die alte zunehmend ersetzen und ihr angeblich in vielerlei Hinsicht überlegen sein sollte. Die Bezeichnung lautete ADODB als Abkürzung für das etwas schräge Microsoft ActiveX Data Objects Data Base.

Ein Hintergrund dafür war die Einführung der Access-Projekte, die den unmittelbaren Zugriff auf Objekte eines verbundenen SQL-Servers erlaubten und sogar deren Verwaltung ermöglichen. Derlei war mit DAO unmöglich, und so nahm man sich der bereits für Visual Basic vorliegenden Implementation von ADO an und pfropfte sie Access auf.

Statt DAO wurde beim Neuanlegen einer Datenbank automatisch der Verweis auf die neue Bibliothek gesetzt. Das änderte indessen nichts daran, dass die Access-Objekte, wie Formulare und Berichte, unter der Haube weiterhin mit DAO arbeiteten.

Diese Inkonsistenz ist neben der Tatsache, dass die Programmierung über ADO deutlich aufwändiger und komplizierter ist, mit ein Grund dafür, dass diese Technik von Entwicklern nicht wirklich angenommen wurde.

So elegant sie bei der Einbindung von Daten auf SQL-Servern ist, so überflüssig beim Zugriff auf die Tabellen der lokalen Access-Datenbank oder eines verknüpften Backends.

Microsoft wurde sich dessen offenbar bewusst, weshalb ab Access 2007 die Umkehr stattfand. Nun sollte DAO nicht nur für JET-Datenbanken, sondern sogar für die Ansprache von SQL-Servern über ODBC eingesetzt werden. Dafür dürfte allerdings nicht nur Einsicht Vater des Gedankens gewesen sein, sondern auch der Fakt, dass die Technik der Access-Projekte nicht mehr weiterentwickelt wurde und nach und nach dem Rotstift anheimfiel.

Auch, wenn ADO mittlerweile ein Stiefkind zu sein scheint, kann es nicht schaden, sich die Datenzugriffsbibliothek einmal genauer anzusehen. Denn sie verfügt über einige interessante Features, die DAO fehlen, weshalb ihr Einsatz in manchen Fällen doch noch sinnvoll sein kann.

ADODB im VBA-Projekt

Den Verweis auf die ADO-Bibliothek legt Access, wie erwähnt, nicht mehr selbst an, wenn Sie eine neue Datenbank erzeugen. Sie müssen Sie selbst einbinden. Dazu öffnen Sie im VBA-Editor über Extras|Verweise… den Verweise-Dialog und klappern dessen Einträge nach der Microsoft ActiveX Data Objects 2.x Library ab. Sie werden gleich mehrere davon finden, die die Versionsnummern 2.1 bis 2.8 tragen. Tatsächlich handelt es sich dabei aber lediglich um verschiedene Typbibliotheken für den gleichen Satz an DLLs, also das gleiche System, die aus Kompatibilitätsgründen angelegt sind. Aktivieren Sie einfach die höchste Version 2.8. Nach dem Schließen des Verweise-Dialogs finden Sie die Bibliothek im VBA-Objektkatalog, wenn Sie im Kombinationsfeld links oben den Eintrag ADODB auswählen.

Die Struktur von ADO

Schon am Umfang der Klassen der Bibliothek ist ersichtlich, dass deren Programmierung etwas komplexer ist, als unter DAO. Um die Bedeutung der einzelnen Objekte verständlich zu machen, ist es nützlich, sie in einen Vergleich zu jenen der DAO-Bibliothek zu setzen. In Bild 1 sind die wichtigsten Objekte gegenübergestellt.

Bild 1: Die Datenzugriffsbibliotheken ADO und DAO in der logischen Gegenüberstellung

Während Sie unter DAO auf die aktuelle Datenbank (Database-Objekt) unmittelbaren Zugriff haben, indem Sie die Funktion CurrentDb des Access-Application-Objekts aufrufen, oder die Methode OpenDatabase des ebenfalls bereits vorliegenden DbEngine-Objekts, muss in ADO erst eine Verbindung zur Datenbank aufgebaut werden.

Das ist auch schon der Hauptunterschied: Access ist beim öffnen einer Datenbank ganz unbemerkt bereits mit der JET-Engine verbandelt. Die darüber liegende Schicht, die Treiber der Access Database Engine (ACE) samt ihrer dateispezifischen ISAM-Treiber, bleibt Ihnen verborgen. Verwendet werden dabei die Treiber für MDB– und ACCDB-Dateien. Neben diesen gibt es ja etwa auch noch jene zum öffnen von Excel-, Text– oder DBase-Dateien. Um diese Schicht brauchen Sie sich nicht zu kümmern – die Integration vollzieht Access selbst. Anders unter ADO: Hier muss zunächst dezidiert der sogenannte Provider angegeben werden.

Dabei handelt es sich Imgrunde um einen im System registrierten Treiber, der zum öffnen einer Datei herangezogen werden soll. Diese Provider werden von Office installiert, teilweise aber auch von Windows oder anderen Anwendungen. Alle Provider sind namentlich gekennzeichnet. So lautet der Name des Providers zum öffnen einer Access-Datenbank aktuell etwa Microsoft.ACE.OLEDB.12.0. Früher nahm man zum Ansprechen einer MDB-Datei den Jet-Provider Microsoft.Jet.OLEDB.4.0. Soll ein MS-SQL-Server verbunden werden, dann heißt der Provider SQLOLEDB.1. Und schließlich kommen weitere DBMS-Server über ODBC ins Spiel, wenn der MSDASQL.1-Provider verwendet wird. Wie die jeweiligen Provider lauten, lässt sich aus Access heraus nicht ermitteln. Greifen Sie im Zweifelsfall zu einer Dokumentation im Internet, wie etwa der Domain connectionsstrings.com. Dort klicken Sie auf das gewünschte das Datenbanksystem, um die Verbindungszeichenfolgen zu erfahren. Die Seite unterscheidet dabei zwischen Zeichenfolgen für ODBC, OLEDB und .NET. Uns interessieren an dieser Stelle nur die OLEDB-Angaben, ein Synonym für ADODB.

Neben dem Namen des Providers finden Sie dort auch noch weitere Angaben, die Sie zum Provider machen können, nämlich die Optionen-Strings, welche die Treiber steuern. Doch dazu später mehr.

Haben Sie die Angaben zum Provider beisammen, so können Sie sich an das Anlegen eines Connection-Objekts machen. ADO kennt kein Database-Objekt, sondern nur das Verbindungsobjekt Connection, welches diesem aber in der Funktionalität ähnelt. Die Verbindung wird über die Methode Open hergestellt. Steht diese, so kann analog zur Database ein Recordset auf die Datenbankobjekte geöffnet werden. Nur lautet die hier verwendete Methode nicht OpenRecordset, sondern Execute. In beiden Fällen wird ein Recordset zurückgegeben.

Allerdings ist ein ADO-Recordset nicht dasselbe, wie ein DAO-Recordset! Zwar gleichen sich dessen Methoden weitgehend, doch es handelt sich dennoch um zwei unterschiedliche Klassen. Wenn Sie Objektvariablen zu diesen Recordsets deklarieren, so geben Sie deshalb ausdrücklich die Bibliothek an, aus dem das Recordset stammen soll:

Dim rs As DAO.Recordset
Dim rs As ADODB.Recordset

Das beugt Verwirrung vor, denn im VBA-Projekt können Sie auf beide Bibliotheken zugleich verweisen!

Die Unterschiede zwischen dem einen und dem anderen Recordset sind marginal. Beide weisen die üblichen Methoden zur Navigation (MoveNext, MoveLast, etc.) auf und haben jeweils eine Fields-Auflistung, über die auf die einzelnen Felder des Ergebnisses zugegriffen werden kann.

Connection anlegen

Gehen wir nun Schritt für Schritt vor, um an die Daten einer Datenbank über ADO zu gelangen.

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