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 (siehe Bild 1).
Bild 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.
Sie haben das Ende des frei verfügbaren Textes erreicht. Möchten Sie ...
Oder bist Du bereits Abonnent? Dann logge Dich gleich hier ein. Die Zugangsdaten findest Du entweder in der aktuellen Print-Ausgabe auf Seite U2 oder beim Online-Abo in der E-Mail, die Du als Abonnent regelmäßig erhältst:
