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 4/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

Erfahren Sie, wie Sie Code für den Zugriff auf DBMS schreiben, der nicht vom gewählten SQL-Server abhängt.

Techniken

VBA, SQL, Klassenprogrammierung

Voraussetzungen

Access 2000 und höher

Beispieldateien

DBMSZugriff.mdb

Shortlink

677

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

Josef Pötzl, Graz

Haben Sie sich nicht auch schon immer gefragt, welche Zugriffstechnik am besten für den Zugriff auf Tabellen in aktiven Datenbanksystemen geeignet ist? Falls Sie dies bereits mit ADODB- und DAO-Methoden getestet haben, wissen Sie vermutlich, dass keine Zugriffsmethode alle Wünsche eines Access-Programmierers erfüllt. Es bleibt also nichts anderes übrig, als die Einschränkungen hinzunehmen oder unterschiedliche Methoden parallel einzusetzen.

Im Beitrag Anmeldung an SQL Server und Co. wurde eine Methodensammlung zum Anmelden an aktive Datenbankmanagementsysteme (DBMS) vorgestellt (s. Shortlink 668). Diese Sammlung erweitern wir nun um eine Klassenstruktur zur Kapselung unterschiedlicher Verbindungstechniken. Voraussetzung zum Testen der nachfolgend vorgestellten Klassen ist eine Datenbank unter MySQL oder Microsoft SQL Server, die Sie über die Methoden des oben vorgestellten Beitrags mit der Frontend-Datenbank verknüpfen. Ist dies erledigt, können Sie mit den Methoden und Eigenschaften sehr viel einfacher auf die Datenbank zugreifen als zuvor - und noch besser: Wenn Sie sich entscheiden, die Backend-Datenbank vom SQL Server nach MySQL zu übertragen oder umgekehrt, brauchen Sie den Code für den Zugriff auf die Daten nicht zu ändern (das gilt wegen unterschiedlicher Dialekte jedoch nicht uneingeschränkt für die enthaltenen SQL-Anweisungen). Bevor wir hinter die Kulissen schauen, hier ein paar Beispiele. Das erste betrifft die Domänenfunktionen wie etwa DCount. Damit können Sie sich die Anzahl der Datensätze einer in der Datenbank enthaltenen oder verknüpften Tabelle wie folgt ausgeben lassen:

Debug.Print DCount("*”, "tblArtikel”)

Die nachfolgend vorgestellten Klassen ermöglichen erstens einen Zugriff auf die gleichen Informationen, allerdings auf Basis eines Recordsets. Handelt es sich um eine verknüpfte Tabelle, verwenden Sie einfach die folgende Anweisung:

Debug.Print CurrentDBConnection.DAO.DCount("*”, "tblArtikel”)

Vielleicht arbeiten Sie gar nicht mit einer Verknüpfung, sondern möchten per ADODB direkt auf die Tabelle des MySQL- oder SQL Servers zugreifen? Dann funktioniert diese Variante:

Debug.Print CurrentDBConnection.ADODB.DCount("*”, "tblArtikel”)

Die Klassen bieten noch eine Reihe weiterer Funktionen, beispielsweise um ein Recordset zu erzeugen. Für eine verknüpfte Tabelle sieht dies so aus:

Set rst = CurrentDBConnection.DAO.OpenRecordset("SELECT * FROM tblArtikel”)

Ist die Tabelle nicht verknüpft, hilft die ADODB-Variante weiter:

Set rst = CurrentDBConnection.ADODB.OpenRecordset("SELECT * FROM tblArtikel”)

Sie können aber auch mit einem DAO-Recordset arbeiten, das via ODBC erzeugt wurde:

Set rst = CurrentDBConnection.ODBC.OpenRecordset("SELECT * FROM tblArtikel”)

Es gibt noch einige weitere Funktionen, mit denen Sie etwa den Connectionstring der aktuell verwendeten Verbindung ausgeben können. Mehr dazu erfahren Sie weiter unten.

Grundlagen

Für den Zugriff von einem Access-Frontend auf ein DBMS stehen unterschiedliche Verbindungstechniken zur Verfügung:

  • Verknüpfte Tabellen und Sichten (ODBC)
  • Pass-Through-Abfragen (ODBC)
  • ADO-Verbindung zur Datenbank (OLEDB)
  • ODBCDirect (ODBC)
  • DAO-Database-Instanz mit ODBC-Connectionstring (ODBC)

Die folgenden Abschnitte stellen diese Möglichkeiten und deren Vor- und Nachteile kurz vor.

Verknüpfte Tabellen und Sichten

Die Tabellen oder Sichten aus der Datenbank werden im Access-Frontend über ODBC verknüpft. Der Zugriff auf die Daten erfolgt über die lokale Frontend-Database-Instanz. Bei Abfragen mit verknüpften Tabellen wird die SQL-Anweisung von Jet beziehungsweise ACE (ab Access 2007) entgegengenommen und für die Weitergabe per ODBC an das Datenbanksystem aufbereitet.

Der ODBC-Manager übernimmt die aufbereitete SQL-Anweisungen und transferiert sie über den ODBC-Treiber an das DBMS. Das DBMS arbeitet die nun erhaltene SQL-Anweisung ab und gibt das Ergebnis an Jet zurück.

Sobald Jet- beziehungsweise VBA-Funktionen in der Abfrage eingesetzt werden, können diese nicht an das DBMS weitergereicht werden und müssen von Jet selbst abgearbeitet werden.

Tipp: Betrachten Sie die vom ODBC-Treiber für den SQL Server aufbereitete SQL-Anweisung und deren Abarbeitung mit dem SQL-Server-Profiler. Der Microsoft SQL Server übernimmt auch beim Einsatz von Access-Abfragen mit verknüpften Tabellen einen Großteil der Datenaufbereitung und nicht - wie oftmals behauptet wird - nur Access und Jet.

Zugriffsweg: Access ï€¢ Jet/ACE ï€¢ ODBC-Manager ï€¢ ODBC-Treiber ï€¢ DBMS

Vorteil: Vorgehensweise wie bei Access/Jet-Tabellen und somit wenig Umstellungsaufwand beim Wechsel von einer Jet-Datenbank zu einer Datenbank in einem aktiven DBMS.

Nachteil: Bei komplexeren Access-Abfragen auf verknüpfte Tabellen kann es zu Geschwindigkeitseinbußen kommen. Außerdem können die Fähigkeiten des DBMS nicht vollständig eingesetzt werden (etwa Einsatz von gespeicherten Prozeduren).

Pass-Through-Abfragen

Pass-Through-Abfragen erhalten über einen ODBC-Connectionstring eine Verbindung zum DBMS. Bei Pass-Through-Abfragen entfällt die Auswertung der SQL-Anweisung durch Jet. Daher muss die in einer Pass-Through-Abfrage enthaltene SQL-Anweisung im SQL-Dialekt des DBMS vorliegen.

Zugriffsweg: Access  ODBC-Manager  ODBC-Treiber  DBMS

Vorteil: Die SQL-Anweisung wird direkt ohne Umweg über Jet im DBMS ausgeführt. Dadurch können die Fähigkeiten des DBMS besser genutzt werden.

Nachteil: Die über eine Pass-Through-Abfrage erhaltenen Datensätze können nicht bearbeitet werden (bei einer verknüpften Sicht sind die Datensätze bearbeitbar, wenn im Access-Frontend ein Primärschlüssel eingestellt wurde).

ADO-Verbindung zur Datenbank

Der Zugriff erfolgt über einen OLEDB-Provider auf das DBMS. Beachten Sie, dass eine dezidierte Verbindung zum DBMS aufgebaut werden muss und nicht die ADODB-Connection des Frontends über CurrentProject.Connection und die verknüpften Tabellen genutzt wird. Denn sonst würde der Zugriff abermals über die ODBC-Verbindung laufen.

Damit die Verbindung direkt zum DBMS aufgebaut werden kann, müssen Sie eine ADODB-Connection mit dem OLEDB-Provider des DBMS öffnen. Für den Zugriff auf einen MSSQL-Server können beispielsweise die OLEDB-Provider "SQLOLEDB" oder "SQLNCLI" verwendet werden. Sollte für ein DBMS, wie bei MySQL, kein spezieller OLEDB-Provider vorhanden sein, können Sie als Brücke zwischen OLEDB und ODBC den Microsoft OLEDB-Provider für ODBC verwenden und für den Verbindungsaufbau den ODBC-Treiber des DBMS einsetzen. In diesem Fall wird zwar intern wieder über ODBC auf das DBMS zugegriffen, trotzdem können Sie die meisten Fähigkeiten der ADO-Bibliothek nutzen. Die in ADODB-Methoden eingesetzten SQL-Anweisungen werden über ADO an den OLEDB-Provider übergeben und von dort an das DBMS weitergereicht - ähnlich, wie bei den Pass-Through-Abfragen. Die SQL-Anweisungen müssen daher im jeweiligen SQL-Dialekt des DBMS verfasst werden.

Zugriffsweg: Access  ADO  OLEDB-Provider  DBMS

Vorteil: Für die meisten aktiven DBMS ist die ADO-Variante die schnellste Zugriffsmethode. Das ADODB-Objektmodell bietet außerdem umfangreichere Methoden für den Datenzugriff als das DAO-Objektmodell (zum Beispiel Ausführung von SQL-Anweisung über ADODB.Command).

Nachteil: Der Programmieraufwand der Standard-ADODB-Methoden ist höher als beim DAO-Zugriff. Datenverarbeitung über ADODB kann nur mit VBA oder Formulare genutzt werden. Der Einsatz für Access-Berichte ist in einer .mdb beziehungsweise .accdb nicht möglich (nur beim Einsatz eines ADP-Frontends erfolgt der Zugriff über ADODB/OLEDB).

ODBCDirect

Mit einem ODBC-Connectionstring wird ein DAO-Arbeitsbereich (DAO.Workspace) erstellt. Diese Zugriffsvariante stellt im Prinzip ein DAO-Gegenstück zur ADODB-Verbindung dar. Die SQL-Anweisungen erfolgen im SQL-Dialekt des DBMS.

Zugriffsweg: Access  ODBCDirect  ODBC-Manager  ODBC-Treiber  DBMS

Da diese Variante ab Access 2007 nicht mehr zur Verfügung steht, wird sie im folgenden Text nicht weiter berücksichtigt.

DAO-Database-Instanz mit ODBC-Connectionstring

Mithilfe eines ODBC-Connectionstrings wird eine DAO-Database-Instanz geöffnet. Die SQL-Anweisungen erfolgen im Access/Jet-SQL-Dialekt. Sie können diese Variante mit dem Vorgehen bei einem Jet-Backend vergleichen, bei dem nicht über verknüpfte Tabellen auf die Tabellen im Backend zugegriffen wird, sondern auf die Backend-Datenbank über eine eigene Database-Instanz.

Zugriffsweg: Access ï€¢ Jet/ACE ï€¢ ODBC-Manager ï€¢ ODBC-Treiber ï€¢ DBMS

Vorteil: Tabellen beziehungsweise Sichten müssen nicht verknüpft werden. Die Datensätze im geöffneten Recordset sind bearbeitbar, wenn die verwendete SQL-Anweisung eine Bearbeitung erlaubt.

Nachteil: Es können keine gespeicherten Prozeduren ausgeführt werden.

Zusammenfassung

Jede Verbindungstechnik hat in einem bestimmten Bereich Vorteile. Aus diesem Grund ist der Einsatz einer Kombination ausgewählter Techniken im Access-Frontend sinnvoll. Für MSSQL oder MySQL könnte etwa folgende Kombination eingesetzt werden:

  • Verknüpfte Tabellen/Sichten zur Datenbearbeitung in Formularen und als Datenbasis für Berichte (Sortierung und Filterung erfolgt über Access/Jet-SQL und wird per ODBC an das DBMS weitergereicht)
  • Pass-Through-Abfragen zur Datenanzeige in Formularen und als Datenbasis für Berichte (SQL-Anweisung kann per VBA angepasst werden)
  • ADO-Methoden für VBA-Zugriffe und ADO-Recordset als Datenbasis für Formulare und Steuerelemente. (Kombinations- und Listenfelder können in einer .mdb-Datei erst ab Access 2002 ein ADODB-Recordset als Datenbasis verwenden)

Vorteil: Die jeweils passende Technik ermöglicht effizienten Datenzugriff und Nutzung der Fähigkeiten des DBMS.

Nachteil: DAO- und ADO-Methoden müssen unterschiedlich programmiert werden. Das erschwert einen Wechsel der Zugriffstechnik.

Beispiel: Recordset öffnen

Das Öffnen eines DAO-Recordsets geschieht durch folgende Anweisungen:

Dim rst As DAO.Recordset

Set rst = CurrentDb.OpenRecordset("SELECT *

FROM Tabelle”, dbOpenDynaset, dbSeeChanges)

Die entsprechende Vorgehensweise für ein ADODB-Recordset benötigt diese Zeilen:

Dim rst As ADODB.Recordset

Set rst = New ADODB.Recordset

rst.Open "SELECT * FROM Tabelle”,

CurrentConnection, adOpenDynamic

Ziel dieses Beitrags

Der Zugriff auf ein DBMS soll standardisiert und DAO- und ADODB-Methoden sollen über eine ähnliche Schnittstelle aufrufbar werden.

Ausgangssituation und Konzept

Ein Access-Frontend wird für den Zugriff auf eine Datenbank in einem aktiven DBMS eingesetzt. Komplexere SQL-Anweisungen werden im DBMS in Form von Sichten und gespeicherten Prozeduren zur Verfügung gestellt. Aus diesem Grund ist der Einsatz von ADODB-Methoden beziehungsweise Pass-Through-Abfragen sinnvoll.

Anforderungen:

  • Unabhängig vom eingesetzten DBMS
  • Modularer Aufbau für flexiblen Einbau in Access-Anwendungen
  • DAO- und ADO-Methoden werden ähnlich aufgerufen.

Lösungsansatz:

  • DBMS-Verbindung wird über eine Schnittstelle zur DbConnectionInfo-Klasse aus dem Beitrag Anmeldung an SQL Server und Co. in Heft 3/2009 (s. Shortlink 668) eingestellt. Die Übergabe der Verbindungsparameter wird jedoch so gestaltet, dass die Zugriffsklassenstruktur auch ohne DbConnectionInfo-Klasse verwendbar ist.
  • Klassenmodule für ADODB (OLEDB), DAO (Jet) und DAO (ODBC) dienen zur Kapselung des Datenzugriffs.
  • Eine zusätzliche Klasse für die Ansteuerung der Zugriffstechniken erleichtert den Methodenaufruf.

Funktionsweise:

Über das Startformular frmAppWatcher wird die Startprozedur StartApplication aufgerufen. Diese Prozedur startet den Verbindungsaufbau und die Instanzierung der Klasse für die Zugriffssteuerung. Die Verbindungsparameter werden über die DbConnectionInfo-Instanz ausgelesen und der Zugriffssteuerung bei Bedarf bereitgestellt. Über die Klasse DbConnectionHandler steht ein Objektmodell zur Verfügung, dessen Elemente Sie bequem über die Punkt-Syntax ansprechen können - zum Beispiel CurrentDBConnection.ODBC.OpenRecordset(...).

Das Objektmodell stellt drei verschiedene Zugriffsvarianten zur Verfügung:

  • ADODB (Klasse AdodbHandler)
  • DAO (Klasse DaoHandler)
  • ODBC (Klasse OdbcHandler)

Zugriffsvariante ADODB

Diese Variante eignet sich für den direkten Zugriff auf die Datenbanken im DBMS. Sie bietet folgende Eigenschaften:

  • ConnectionString: OLEDB-Connectionstring für DBMS-Verbindung
  • CurrentConnection: ADODB-Connection zum DBMS

Außerdem können Sie folgende Methoden für die Ausführung von SQL-Anweisungen verwenden:

  • Execute: Execute-Methode zum Ausführen von SQL-Anweisungen. Syntax: Execute(CommandText, [RecordsAffected], [Options]) As ADODB.Recordset
  • InsertIdentityReturn: Methode zum Ausführen einer Insert-SQL-Anweisung auf eine Tabelle mit Rückgabe des Identity/Autowerts (IdentityTable kann für MSSQL verwendet werden). Syntax: InsertIdentityReturn(InsertSQL, [IdentityTable]) As Variant

Methoden zum Öffnen von Recordsets:

  • OpenRecordset: Funktioniert wie die herkömmliche OpenRecordset-Anweisung. Syntax: OpenRecordset(Source, [CursorType], [LockType], [CursorLocation]) As ADODB.Recordset
  • OpenRecordsetCommandParam: Öffnet ein ADODB-Recordset mittels ADODB-Command. Syntax: OpenRecordsetCommandParam(CmdText, CmdType, [commandParamDefs]) As ADODB.Recordset

Recordset-Ersatzfunktionen für Domänenfunktionen:

  • DLookup: Funktioniert wie die herkömmliche DLookup-Funktion. Syntax: DLookup(Expr As String, Domain, [Criteria]) As Variant
  • DLookupSQL: Ähnlich DLookup - nur für direkte Übergabe einer SQL-Anweisung. Damit wird etwa unter ADODB der Einsatz einer gespeicherten Prozedur oder Funktion möglich. Syntax: DLookupSQL(sSQL, [index]) As Variant
  • DSum(Expr, Domain, [Criteria]) As Variant
  • DCount(Expr, Domain, [Criteria]) As Long
  • DMax (Expr, Domain, [Criteria]) As Variant
  • DMin (Expr, Domain, [Criteria]) As Variant

Zugriffsvariante DAO

Diese Variante ermöglicht den Zugriff über verknüpfte Tabellen beziehungsweise den Einsatz von CurrentDb des Frontends. Die Klasse bietet nur eine Eigenschaft:

  • CurrentDb: Liefert eine DAO.Database-Instanz des Frontends.

Die Methoden für die Ausführung von SQL-Anweisungen sehen so aus:

  • Execute: Führt eine DAO-Aktionsabfrage aus. Achtung: Die Execute-Parameter weichen von der DAO-Execute-Methode ab, da RecordsAffected ergänzt wurde. Syntax: Execute(CommandText, [RecordsAffected], [Options]) As DAO.Recordset
  • InsertIdentityReturn: Liefert den Autowert des zuletzt hinzugefügten Datensatzes. Die Methode funktioniert nicht mit MySQL. Für MySQL ist die ADODB-Variante zu verwenden. Syntax: InsertIdentityReturn(InsertSQL) As Variant

Methoden zum Öffnen von Recordsets:

  • OpenRecordset(Source, [RecordsetType], [RecordsetOptions], [LockEdit]) As DAO.Recordset

Recordset-Ersatzfunktionen für Domänenfunktionen:

  • DLookup: DLookup(Expr As String, Domain, [Criteria]) As Variant
  • Weitere Funktionen wie unter DAO.

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:

Anmeldung an SQL Server und Co.

Der DBMS-Connection-Wizard

Performanter Webzugriff auf MySQL-Datenbanken

Access, MySQL und Datenzugriff

Access, MySQL und Berechtigungsverwaltung

Gespeicherte Prozeduren

Von Access nach MySQL, Teil 2

Upsizing von Access nach SQL Server: Tabellen

Benutzerdefinierte Funktionen im MS SQL Server

Trigger

Datensicherung mit dem MS SQL Server

Verschlüsselung und Komprimieren im Backend

Ereignisprozeduren implantieren

Abfragen von Access zum SQL Server

© 2003-2015 André Minhorst Alle Rechte vorbehalten.