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 1/2007.

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

Lernen Sie eine Technik kennen, mit der Sie Datensatzgruppen verbindungslos im Speicher halten.

Techniken

VBA, ADO

Voraussetzungen

Access 2000 und höher

Beispieldatei

DisconnectedRecordsets.mdb

Shortlink

437

Disconnected Recordsets

Uwe Ricken, Erzhausen

Konfigurationsdaten, Meldungen oder SQL-Befehle kann man in passenden Tabellen speichern und bei Bedarf per DLookup oder DAO auf diese zugreifen. Da diese Daten sich in der Regel nur selten ändern, kann man sie getrost einmal zu Beginn der Session auslesen und dann auf die temporär gespeicherten Daten zugreifen. Das spart Ressourcen und erhöht die Zugriffsgeschwindigkeit - dank ADO und Disconnected Recordsets.

Neue Datenzugriffstechnik mit ADO

Das Schlagwort „Disconnected Recordsets“ geisterte durch die Welt der Programmierung, seit Microsoft die Version 2.0 von „ADO“ (ActiveX Data Objects) für Datenbanken publiziert hatte. ADO war ursprünglich als Nachfolger für DAO (Data Access Objects) geplant.

Der Datenbankzugriff mit ADO weist gegenüber DAO einige Verbesserungen in der Performance auf, wenn SQL-Server-Backends zum Einsatz kommen. Der Hemmschuh ist in diesem Fall die von DAO für den Zugriff benötigte ODBC-Schnittstelle. Für die Festlegung des Datenbankzugriffs wird ein OLE DB-Provider benötigt – eine der Neuerungen von ADO. Mit Hilfe dieses Providers können Sie dem Connection-Objekt mitteilen, auf welche Datenbank es zugreifen soll und um welche Version es sich dabei handelt. Mit ADO lassen sich nahezu alle gebräuchlichen Datenbanken wie etwa Microsoft Access, SQL-Server, Oracle oder Informix ansprechen.

Die wichtigsten drei Komponenten des ADO-Datenmodells sind folgende:

  • Connection („Verbindung“): Enthält den Ort und den Namen der angesprochenen Datenbank, braucht für eine angesprochene Datenbank nur einmal definiert zu werden.
  • Recordset („Datensatz-Objekt“): Der Verbindung untergeordnetes und abhängiges Objekt, das Daten in Form von Tabellen oder Abfragen zurückgibt; ist die Grundlage der folgenden Ausführungen.
  • Command („Befehls-Objekt“): Das Command-Objekt benötigt keine Connection und dient dem Ändern der Datenbank und der enthaltenen Daten mit Befehlen wie UPDATE, CREATE TABLE oder INSERT INTO.

Vergleich des Zugriffs auf Recordsets

Die folgenden Codebeispiele zeigen den Unterschied des Datenzugriffs mit DAO und ADO. Beachten Sie, dass das DAO-Beispiel nicht mit Access-Projekten funktioniert. Das hängt damit zusammen, dass DAO ausschließlich mit der JET-Engine arbeiten kann, egal, ob die Relationen aus einer Access-Datenbank oder einer ODBC-Datenbank stammen.

Öffnen eines Recordsets mit DAO

Um mittels DAO ein Recordset zu öffnen, benötigt man nicht viel. Das Codebeispiel aus Listing 1 verwendet die OpenRecordset-Methode zum Erzeugen des Recordsets und liefert dieses als Funktionswert an die aufrufende Routine zurück.

Listing 1: Öffnen eines Recordset-Objekts mit DAO

Public Function OpenRecordSet_By_DAO() As DAO.RecordSet

     On Error GoTo ErrorHandler

     Dim db As DAO.Database

     Dim rst As DAO.Recordset

     Set db = DBEngine(0)(0)

     Set rst = db.OpenRecordset("tblStammdaten", dbOpenDynaset)

     If Not rst Is Nothing Then

         Set OpenRecordSet_By_DAO = rst

     End If

ExitCode:

     On Error Resume Next

     Set rst = Nothing

     Set db = Nothing

     Exit Function

ErrorHandler:

     MsgBox Err.Description, vbInformation, "OpenRecordSet_By_DAO"

     Resume ExitCode

End Function

Öffnen eines Recordsets mittels ADO

Wollen Sie die gleiche Funktion mit ADO nachbilden, müssen Sie ein paar wenige Codezeilen mehr schreiben. Dies ist aber dadurch bedingt, dass ADO wesentlich mehr Möglichkeiten besitzt als DAO. Der Unterschied im Code wird schnell ersichtlich. Der Code für den Zugriff mittels ADO ist zwar etwas länger, dafür aber auch strukturierter (s. Listing 2). Zunächst baut die Routine durch Setzen der Eigenschaft ActiveConnection eine Verbindung zur Datenquelle auf.

Listing 2: Öffnen eines Recordset-Objekts mit ADO

Public Function OpenRecordSet_By_ADO() As ADODB.Recordset

     On Error GoTo ErrorHandler

     Dim rst As ADODB.Recordset

     Set rst = New ADODB.Recordset

     With rst

         Set .ActiveConnection = CurrentProject.Connection

         .CursorLocation = adUseServer

         .CursorType = adOpenDynamic

         .Source = "tblStammdaten"

         .Open

     End With

     If Not rst Is Nothing Then

         Set OpenRecordSet_By_ADO = rst

     End If

ExitCode:

     On Error Resume Next

     Set rst = Nothing

     Exit Function

ErrorHandler:

     MsgBox Err.Description, vbInformation, "OpenRecordSet_By_ADO"

     Resume ExitCode

End Function

Im nächsten Schritt konfiguriert sie das zu füllende Recordset und öffnet es anschließend mit der Open-Methode. Was bei DAO ein Einzeiler ist, lässt sich auch mit ADO in einer Zeile realisieren, allerdings scheint diese Variante unübersichtlicher – auch im Vergleich mit dem passenden DAO-Aufruf, da ADO mehr Optionen bereitstellt:

rst.Open [Source],
[ActiveConnection], [CursorType], [LockType], [Options]

Die Eigenschaft ActiveConnection ermöglicht es dem Recordset, eine Verbindung zur Datenbank aufzubauen. Die so genannten Connectionstrings für die gängigsten Datenquellen findet man sowohl im Internet [1] als auch in der Online-Hilfe von Microsoft. Die Codes zu obigem Beispiel finden Sie im Formular Demonstration DAO - ADO der Beispieldatenbank (s. Abb. 1).

pic001.tif

Abb. 1: Beispielformular zum Erzeugen eines Recordsets mit DAO und ADO

Was sind
„Disconnected Recordsets“?

Ab ADO 2.0 (wurde 1998/1999 im Rahmen der Einführung von MDAC 2.0 ausgeliefert) können Recordsets von ihrer Verbindung getrennt werden. Der Zeiger eines Recordsets auf die von ihm verwendete Datenquelle wird durch die Eigenschaft ActiveConnection repräsentiert. Diese Eigenschaft kann seit der Version 2.0 nicht nur ausgelesen, sondern auch neu gesetzt werden.

Dabei kann sie sowohl auf Nothing als auch auf eine andere Verbindung als die ursprüngliche gesetzt werden. Wenn ein Recordset mit folgender Anweisung von seiner Datenquelle abgekoppelt wird, kann es immer noch bearbeitet werden:

Set .ActiveConnection = Nothing

Voraussetzung hierfür ist jedoch, dass ein Cursor auf der Client-Seite verwendet wird:

.CursorLocation = adUseClient

Außerdem muss die Eigenschaft LockType den Wert adLockBatchOptimistic aufweisen:

.LockType = adLockBatch

Dadurch werden alle Datensätze des Recordsets im Speicher gehalten und auf Seiten der Datenbank keine Sperren gesetzt. Das Recordset führt seine Statusinformationen korrekt mit. Sie können zu einem späteren Zeitpunkt die Verbindung wieder herstellen und mit der Methode UpdateBatch die Änderungen wieder in die Datenbank einspielen.

Warum „Disconnected Recordsets“?

Die Verwendung von Disconnected Recordsets wird im ersten Augenblick nicht unbedingt einleuchtend sein, insbesondere, wenn man (wie auch ich selbst) bisher immer mit JET-Datenbanken oder zumindest mit sehr leistungsfähigen Datenbank-Backends gearbeitet hat.

Ein klassisches Beispiel für die Verwendung von Disconnected Recordsets bietet das Internet. Stellen Sie sich vor, Sie haben einen gut laufenden Online-Shop. Jede Listbox befüllen Sie mit Daten aus Ihrem Artikelstamm.

Bei jeder Aktualisierung der Seite würden bei einer bestehenden Verbindung des Recordsets zur Datenquelle die Daten erneut aus der Datenbank gelesen werden. Sollte gerade nur ein Käufer in Ihrem Shop einkaufen, wäre diese Performance-Bremse noch zu ertragen – stellen Sie sich aber mal vor, Sie seien der Betreiber von Amazon, EBay, etc.

Es wird schnell klar, wo der Vorteil von Disconnected Recordsets liegt – der Zugriff auf die Datenbank erfolgt einmalig und die Anwendung kann mit den Daten lokal im Arbeitsspeicher des Computers arbeiten. Es erklärt sich von selbst, dass die Verwendung von Disconnected Recordsets nicht geeignet ist, wenn Sie eine Datenbanklösung einsetzen, bei der es auf Aktualität der Daten ankommt.

Anwendungsbeispiele für
„Disconnected Recordsets“

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:

© 2003-2015 André Minhorst Alle Rechte vorbehalten.