{"id":55000288,"date":"2016-04-01T00:00:00","date_gmt":"2020-01-24T15:59:25","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=288"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"ADODB_als_Alternative_zu_DAO","status":"publish","type":"post","link":"https:\/\/access-basics.de\/index.php\/ADODB_als_Alternative_zu_DAO.html","title":{"rendered":"ADODB als Alternative zu DAO"},"content":{"rendered":"

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.<\/p>\n

Beispieldatenbank<\/h2>\n

Die Beispiele dieses Artikels finden Sie in der Datenbank 1508_ADO.zip<\/b>.<\/p>\n

Datenzugriffsbibliotheken<\/h2>\n

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

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

Statt DAO<\/b> 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<\/b> arbeiteten.<\/p>\n

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

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.<\/p>\n

Microsoft wurde sich dessen offenbar bewusst, weshalb ab Access 2007<\/b> die Umkehr stattfand. Nun sollte DAO<\/b> nicht nur für JET-Datenbanken<\/b>, sondern sogar für die Ansprache von SQL-Servern über ODBC<\/b> 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<\/b> nicht mehr weiterentwickelt wurde und nach und nach dem Rotstift anheimfiel.<\/p>\n

Auch, wenn ADO<\/b> 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<\/b> fehlen, weshalb ihr Einsatz in manchen Fällen doch noch sinnvoll sein kann.<\/p>\n

ADODB im VBA-Projekt<\/h2>\n

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… <\/b>den Verweise-Dialog<\/b> und klappern dessen Einträge nach der Microsoft ActiveX Data Objects 2.x Library<\/b> ab. Sie werden gleich mehrere davon finden, die die Versionsnummern 2.1<\/b> bis 2.8<\/b> 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<\/b>. Nach dem Schließen des Verweise-Dialogs <\/b>finden Sie die Bibliothek im VBA-Objektkatalog, wenn Sie im Kombinationsfeld links oben den Eintrag ADODB<\/b> auswählen.<\/p>\n

Die Struktur von ADO<\/h2>\n

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.<\/p>\n

\"Die<\/a><\/p>\n

Bild 1: Die Datenzugriffsbibliotheken ADO und DAO in der logischen Gegenüberstellung<\/p>\n

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

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

Dabei handelt es sich Imgrunde um einen im System registrierten Treiber, der zum öffnen einer Datei herangezogen werden soll. Diese Provider<\/b> werden von Office<\/b> installiert, teilweise aber auch von Windows<\/b> oder anderen Anwendungen. Alle Provider<\/b> sind namentlich gekennzeichnet. So lautet der Name des Providers<\/b> zum öffnen einer Access-Datenbank aktuell etwa Microsoft.ACE.OLEDB.12.0<\/b>. Früher nahm man zum Ansprechen einer MDB-Datei <\/b>den Jet-Provider Microsoft.Jet.OLEDB.4.0<\/b>. Soll ein MS-SQL-Server<\/b> verbunden werden, dann heißt der Provider SQLOLEDB.1<\/b>. Und schließlich kommen weitere DBMS-Server<\/b> über ODBC<\/b> ins Spiel, wenn der MSDASQL.1<\/b>-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<\/b>. Dort klicken Sie auf das gewünschte das Datenbanksystem, um die Verbindungszeichenfolgen zu erfahren. Die Seite unterscheidet dabei zwischen Zeichenfolgen für ODBC<\/b>, OLEDB<\/b> und .NET<\/b>. Uns interessieren an dieser Stelle nur die OLEDB-Angaben<\/b>, ein Synonym für ADODB<\/b>.<\/p>\n

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

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

Allerdings ist ein ADO-Recordset<\/b> nicht dasselbe, wie ein DAO-Recordset<\/b>! 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<\/b> stammen soll:<\/p>\n

Dim <\/span>rs As <\/span>DAO.Recordset\r\nDim <\/span>rs As <\/span>ADODB.Recordset<\/pre>\n
Das beugt Verwirrung vor, denn im VBA-Projekt können Sie auf beide Bibliotheken zugleich verweisen!<\/p>\n
Die Unterschiede zwischen dem einen und dem anderen Recordset<\/b> sind marginal. Beide weisen die üblichen Methoden zur Navigation (MoveNext<\/b>, MoveLast<\/b>, etc.) auf und haben jeweils eine Fields-Auflistung<\/b>, über die auf die einzelnen Felder des Ergebnisses zugegriffen werden kann. <\/p>\n
Connection anlegen<\/h2>\n
Gehen wir nun Schritt für Schritt vor, um an die Daten einer Datenbank über ADO<\/b> zu gelangen.<\/p>\n
Dass Access kein ADO-Pendant zu CurrentDb<\/b> enthält, stimmt nicht ganz. Seit Einführung von ADODB<\/b> gibt es das CurrentProject-Objekt<\/b>. Dessen Eigenschaft Connection<\/b> stellt die ADO-Connection<\/b> zur aktuellen Datenbank dar. Sie können es direkt verwenden, um ein ADO-Recordset<\/b> zu öffnen:<\/p>\n
Dim <\/span>con As <\/span>ADODB.Connection\r\nDim <\/span>rs As <\/span>ADODB.Recordset\r\nSet<\/span> con = _\r\n    CurrentProject.Connection\r\nSet<\/span> rs = _\r\n   con.Execute( _\r\n   \"SELECT * FROM tblKunden\")\r\nDebug.Print<\/span> rs(3).Value<\/pre>\n
Hier wird zunächst mit der Connection-Variablen<\/b> con<\/b> auf das Connection-Object<\/b> von CurrentProject<\/b> verwiesen. Das Recordset<\/b> wird über die Execute<\/b>-Anweisung der Connection<\/b> gefüllt, welcher der gewünschte SQL-Ausdruck übergeben wird. Im Beispiel ist das der komplette Inhalt der Tabelle tblKunden<\/b>. Schließlich wird das Feld Nummer 3 und dessen Wert abgefragt. (Die 3 in Klammern ist die abgekürzte Syntax für rs.Fields(3).Value<\/b>, da die Fields<\/b>-Auslistung die Standardeigenschaft eines ADO-Recordsets<\/b> ist.)<\/p>\n
Zum Vergleich die analoge Routine in der DAO<\/b>-Version:<\/p>\n
Dim <\/span>dbs As <\/span>Database\r\nDim <\/span>rs As <\/span>DAO.Recordset\r\nSet<\/span> dbs = CurrentDb\r\nSet<\/span> rs = dbs.OpenRecordset( _\r\n     \"SELECT * FROM tblKunden\")\r\nDebug.Print<\/span> rs(3).Value<\/pre>\n
Wenn Sie nicht die aktuelle Datenbank ansprechen möchten, sondern eine andere Access-Datei, so muss ein Connection-Objekt von Grund auf neu erzeugt werden:<\/p>\n
Dim <\/span>con As <\/span>ADODB.Connection\r\nSet<\/span> con = New<\/span> ADODB.Connection\r\ncon.Provider = _\r\n    \"Microsoft.ACE.OLEDB.12.0\"<\/pre>\n
über die New<\/b>-Anweisung wird ein neues Connection-Objekt<\/b> angelegt. Damit es weiß, welche Treiber zur Anwendung kommen sollen, wird der Provider für ACE-Datenbanken<\/b> angegeben. Damit ist die oberste Schicht klargestellt.<\/p>\n
Doch woher weiß die Connection, welches das Objekt der Begierde, die Datenbankdatei, ist Die Angabe des  Pfads muss in der Eigenschaft ConnectionString untergebracht werden:<\/p>\n
con.ConnectionString = _\r\n\"Data Source=c:\\xyz\\test.accdb;\"<\/pre>\n
Der ConnectionString<\/b> ist der Ort, wo alle Optionen zur Verbindung eingestellt werden. Im Falle einer ACE-Datenbank<\/b>, also einer MDB<\/b> oder ACCDB<\/b>, lautet dabei die Option für den Zugriffspfad Data Source<\/b>. Bei anderen Providern könnte dieser Ausdruck auch einen anderen Namen haben.<\/p>\n
Zusätzlich lassen sich weitere Optionen durch Semikola getrennt im String einbauen:<\/p>\n
\"Data Source=c:\\datenbanken\\test.accdb;Mode=Share Deny None;\"<\/pre>\n
Mit Mode<\/b> wird bestimmt, dass der Datenzugriff ohne Mehrbenutzersperren erfolgen soll. Und selbst der Provider<\/b> kann hier untergebracht werden, was das Setzen in der Eigenschaft .Provider<\/b> überflüssig macht:<\/p>\n
\"Provider=Microsoft.ACE.OLEDB.12.0;Data Source=c:\\datenbanken\\test.accdb;Mode=Share Deny None;\"<\/pre>\n
Um eine Vorstellung zu bekommen, welche weiteren Optionen gesetzt sein können, setzen Sie diesen Ausdruck im VBA-Direktfenster ab:<\/p>\n
 CurrentProject.Connection. _\r\n    ConnectionString<\/pre>\n
Auf eine Abbildung des Ergebnisses wird hier verzichtet – Access setzt Unmengen ACE-spezifischer Verbindungsoptionen.<\/p>\n
Sind alle nötigen Angaben im ConnectionString<\/b> gemacht, so kann es an das physische Herstellen der Verbindung gehen, welches die Open-Methode<\/b> bewirkt:<\/p>\n
con.Open<\/pre>\n
Tritt kein Fehler bei dieser Anweisung auf, so ist die Verbindung geöffnet und bereit zum Abfragen oder Schreiben von Daten über die Execute-Methode<\/b>, wie im Recordset-Beispiel oben.<\/p>\n
ADO-Routinen<\/h2>\n
Da der Schreibaufwand bei ADO-Programmierung etwas höher ist, als bei DAO, empfiehlt es sich, für grundlegende Aufgaben ein separates VBA-Modul anzulegen. In der Beispieldatenbank nennt dieses sich mdlADODB<\/b>. Im Folgenden sind einige Abschnitte des Moduls dargestellt.<\/p>\n
MyConnectString<\/b> (Listing 1) ist eine Hilfsfunktion, die eine gültige Verbindungszeichenfolge zurückgibt.  Sie beschränkt sich auf das Zusammensetzen des ConnectionStrings<\/b> über String-Verkettung. Neben dem Provider<\/b> wird der Pfad zur anzusprechenden Access-Datenbank (1508_Backend.accdb<\/b>) im Verzeichnis der aktuellen Datenbank (CurrentProject.Path<\/b>) hier hartkodiert eingebaut. So eine Hilfsfunktion ist unter Umständen sinnvoll, damit der String nicht an mehreren Stellen im Code neu aufgebaut werden muss.<\/p>\n
Function <\/span>MyConnectString() As String<\/span>\r\n     MyConnectString = \"Provider=Microsoft.ACE.OLEDB.12.0;\" & _\r\n         \"Data Source=\" & CurrentProject.Path & \"\\1508_Backend.accdb;\" & _\r\n         \"Mode=Share Deny None;\"\r\nEnd Function<\/span><\/pre>\n
Listing 1: Zusammensetzen eines ConnectionStrings für ADO<\/p>\n
Auch das Connection<\/b>-Objekt wird in einer eigenen Prozedur angelegt, die den Namen DBConnection<\/b> trägt. In Listing 2 wird dabei zunächst ermittelt, ob der Parameter sConnect<\/b> leer ist. In diesem Fall wird das Connection-Objekt<\/b> der aktuellen Datenbank zurückgegeben. Andernfalls wird eine neue Connection<\/b> angelegt, deren ConnectionString<\/b> gesetzt und schließlich die Verbindung über Open<\/b> geöffnet.<\/p>\n
Function <\/span>DBConnection(Optional<\/span> sConnect As String<\/span>) As <\/span>ADODB.Connection\r\n     If <\/span>Len<\/span>(sConnect) = 0 Then<\/span>\r\n         Set<\/span> DBConnection = CurrentProject.Connection\r\n     Else<\/span>\r\n         Set<\/span> DBConnection = New<\/span> ADODB.Connection\r\n         DBConnection.ConnectionString = sConnect\r\n         DBConnection.CursorLocation = adUseClient\r\n         DBConnection.Open\r\n     End If<\/span>\r\nEnd Function<\/span><\/pre>\n
Listing 2: Funktion zum Zurückgeben eines ADO-Connection-Objekts<\/p>\n
Möchten Sie weiterlesen? Dann lösen Sie Ihr Ticket!<\/span>
\nHier geht es zur Bestellung des Jahresabonnements des Magazins Access [basics]<\/strong>:<\/span>
\nZur Bestellung ...<\/a><\/span>
\nDanach greifen Sie sofort auf alle rund 400 Artikel<\/strong> unseres Angebots zu - auch auf diesen hier!<\/span>
\nOder haben Sie bereits Zugangsdaten? Dann loggen Sie sich gleich hier ein:<\/span><\/p>\n<\/div>\n\n\t\n\t
\n\n\t\t\n\t\t