<\/p>\n
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.<\/b><\/p>\n<\/p><\/div>\n Neue Datenzugriffstechnik mit ADO<\/p>\n 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. <\/p>\n 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.<\/p>\n Die wichtigsten drei Komponenten des ADO-Datenmodells sind folgende:<\/p>\n Vergleich des Zugriffs auf Recordsets<\/b><\/p>\n 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.<\/p>\n öffnen eines Recordsets mit DAO<\/p>\n Um mittels DAO ein Recordset zu öffnen, benötigt man nicht viel. Das Codebeispiel aus Listing 1 verwendet die OpenRecordset<\/b>-Methode zum Erzeugen des Recordsets und liefert dieses als Funktionswert an die aufrufende Routine zurück.<\/p>\n Listing 1: öffnen eines Recordset-Objekts mit DAO<\/p>\n öffnen eines Recordsets mittels ADO<\/b><\/p>\n 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<\/b> eine Verbindung zur Datenquelle auf.<\/p>\n Listing 2: öffnen eines Recordset-Objekts mit ADO<\/p>\n Im nächsten Schritt konfiguriert sie das zu füllende Recordset und öffnet es anschließend mit der Open<\/b>-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:<\/p>\n Die Eigenschaft ActiveConnection <\/b>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 <\/b>der Beispieldatenbank (siehe Bild 1).<\/p>\n Bild 1: Beispielformular zum Erzeugen eines Recordsets mit DAO und ADO<\/span><\/b><\/p>\n<\/p><\/div>\n Was sind 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 <\/b>repräsentiert. Diese Eigenschaft kann seit der Version 2.0 nicht nur ausgelesen, sondern auch neu gesetzt werden.<\/p>\n Dabei kann sie sowohl auf Nothing <\/b>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:<\/p>\n Voraussetzung hierfür ist jedoch, dass ein Cursor auf der Client-Seite verwendet wird:<\/p>\n Außerdem muss die Eigenschaft LockType <\/b>den Wert adLockBatchOptimistic <\/b>aufweisen:<\/p>\n 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 <\/b>die änderungen wieder in die Datenbank einspielen.<\/p>\n Warum „Disconnected Recordsets“<\/b><\/p>\n Die Verwendung von Disconnected Recordsets<\/b> 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. <\/p>\n Ein klassisches Beispiel für die Verwendung von Disconnected Recordsets<\/b> bietet das Internet. Stellen Sie sich vor, Sie haben einen gut laufenden Online-Shop. Jede Listbox befüllen Sie mit Daten aus Ihrem Artikelstamm.<\/p>\n 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. <\/p>\n Es wird schnell klar, wo der Vorteil von Disconnected Recordsets<\/b> 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<\/b> nicht geeignet ist, wenn Sie eine Datenbanklösung einsetzen, bei der es auf Aktualität der Daten ankommt.<\/p>\n <\/p>\n Anwendungsbeispiele für Nicht nur für Internet-Anwendungen können Disconnected Recordsets<\/b> hilfreich sein – auch Ihre Datenbankanwendung können Sie unter Umständen mit einer Leistungssteigerung versehen, wenn Sie statische Daten mit einem Disconnected Recordset<\/b> in den Arbeitsspeicher verlagern. Die folgenden Beispiele verdeutlichen dies:<\/p>\n Erstellen eines „Disconnected Recordsets“<\/b><\/p>\n Um die Verbindung eines Recordsets zur Datenbank zu trennen, müssen Sie lediglich die Eigenschaft ActiveConnection <\/b>des Recordsets auf Nothing <\/b>setzen. Dadurch behält das Recordset seine Eigenschaften und Daten, hat aber keine Verbindung mehr zur Datenquelle. Die folgenden Beispiele demonstrieren diese Technik.<\/p>\n Datenbankbeispiel für die Verwendung von „Disconnected Recordsets“<\/b><\/p>\n Das nachfolgende Beispiel soll die Vorteile von Disconnected Recordsets<\/b> bei der täglichen Arbeit mit Microsoft Access verdeutlichen. Weiter oben finden Sie einige Beispiele für die Anwendung von Disconnected Recordset<\/b>. Nun sollen Sie die oben beschriebenen Szenarien an einem einfachen Beispiel nachvollziehen.<\/p>\n Beschreibung des Szenarios und der Gegeben sei eine Tabelle, in der Texte und Anweisungen Ihrer Anwendung gespeichert sind, die Sie während der Laufzeit dynamisch anzeigen. Diese Tabelle dient als Konfigurationstabelle für die MsgBox<\/b>-Anweisung und ist wie in Bild 2 aufgebaut.<\/p>\n Bild 2: Aufbau einer Tabelle zum Speichern von Meldungstexten<\/span><\/b><\/p>\n<\/p><\/div>\n üblicherweise würde man den Text und die Konfiguration mit einer Funktion auslesen, die bei jedem Zugriff dynamisch auf die Relation zugreift (s. Listing 3). Der Aufruf der obigen Funktion erfolgt so:<\/p>\n Listing 3: Auslesen einer Message durch direkten Tabellenzugriff<\/p>\n So weit, so gut – leider wird jedes Mal, wenn Sie eine Meldung ausgeben möchten, eine Verbindung zur Datenbank hergestellt und anschließend eine Abfrage auf die Tabelle durchgeführt. Das macht eigentlich keinen Sinn, da ja in der Regel die Meldungen nicht so häufig aktualisiert werden.<\/p>\n Ziel der überarbeitung soll nun sein, dass für zukünftige Erweiterungen der Zugriff auf Konfigurationen nicht mehr mittels einzelner Funktionen, sondern lediglich durch die Methoden einer Klasse stattfindet.<\/p>\n Weiterhin sollen Konfigurationsdaten nur noch einmal von der Datenbank ermittelt werden – anschließende Lesezugriffe erfolgen dann über ein im Arbeitspeicher gehaltenes Disconnected Recordset<\/b>.<\/p>\n Aufteilung der Aufgaben in Klassen<\/b><\/p>\n Das obige Szenario stammt aus der Realität – aus der des Autors nämlich. Je mehr Konfigurationstabellen es gab, umso mehr Funktionen waren notwendig, um die Daten aus diesen Konfigurationstabellen auszulesen.<\/p>\n Das brachte unter anderem den Nachteil mit sich, dass man alle Funktionen kennen muss, die auf die Konfigurationstabellen zugreifen.<\/p>\n Durch die Kapselung in Klassen kann man diese Vorgehensweise sehr stark vereinfachen – man muss lediglich wissen, wie die Klasse heißt, über die man an die Konfigurationsdaten herankommt.<\/p>\n Sie benötigen also mindestens zwei Klassen. Die erste Klasse dient als „Container“ für die Aufrufe aus den Konfigurationsklassen – diese Klasse soll ConfigData <\/b>heißen. Desweiteren benötigen Sie für jede Art von Konfiguration eine separate Klasse.<\/p>\n Wenn Sie beispielsweise SQL-Anweisungen in Tabellen speichern, erstellen Sie eine Klasse mit dem Namen SQL<\/b>; speichern Sie Meldungen in Tabellen, erstellen Sie eine weitere Klasse mit dem Namen Meldungen<\/b>.<\/p>\n Für das obige Beispiel nennen Sie die Klasse MessageText<\/b>. Um ein Klassenobjekt in Microsoft Access zu erstellen, wechseln Sie in den VBA-Editor von Access und wählen den Menüeintrag Einfügen\/Klassenmodul <\/b>aus. Speichern Sie anschließend das Modul unter dem Namen Messages<\/b>. Nachdem die Klasse in Microsoft Access gespeichert ist, können Sie mit der Programmierung beginnen. Die Klasse soll beim Initialisieren automatisch die Daten aus der Datenbank in ein Recordset einlesen und anschließend die Verbindung zur Datenquelle wieder schließen.<\/p>\n Eine Klasse besitzt zwei Standardmethoden, die Sie ausprogrammieren können. Die Methode Class_Initialize <\/b>wird automatisch ausgeführt, sobald Sie eine Klasse in Ihrem Code instanzieren, die Methode Class_Terminate <\/b>beim Zerstören der Klasse (etwa durch Setzen der Objektvariable auf Nothing<\/b>).<\/p>\n Das Einlesen der Daten in das Recordset erfolgt also logischerweise innerhalb des Initialize<\/b>-Ereignisses, der Code sieht wie in Listing 4 aus.<\/p>\n Listing 4: Einlesen einer Tabelle in ein Recordset beim Instanzieren der Klasse Messages<\/p>\n Um sicherzustellen, dass beim Zerstören der Klasse auch das Recordset im Nirwana des Arbeitsspeichers verschwindet, soll die Ereignisprozedur Class_Terminate <\/b>die passende Objektvariable auf Nothing <\/b>setzen (s. Listing 5).<\/p>\n Listing 5: Schließen des Recordset-Objekts beim Zerstören der Klasse Messages<\/p>\n Nun müssen Sie noch dafür sorgen, dass Sie die Möglichkeit haben, auf das Recordset von außen zuzugreifen. Erstellen Sie dazu noch eine Klasseneigenschaft. Die passende Property Get<\/b>-Prozedur liefert an die aufrufende Funktion das Recordset zurück, das zuvor in der Routine Class_Initialize <\/b>geöffnet wurde:<\/p>\n Mit den beiden Ereignisprozeduren Class_Initialize <\/b>und Class_Terminate <\/b>sowie der Property Get<\/b>-Prozedur Source <\/b>haben Sie die Voraussetzung für den Zugriff auf ein Disconnected Recordset <\/b>geschaffen.<\/p>\n Die Klasse füllt das Recordset beim ersten Zugriff und stellt seine im Arbeitsspeicher befindlichen Inhalt von nun an bereit.<\/p>\n Nun brauchen Sie nur noch eine Funktion, die den gewünschten Datensatz des Recordsets beschafft, und diese bringen Sie wie oben erläutert wiederum in einer Klasse unter. Den kompletten Code dieser Klasse namens ConfigData <\/b>finden Sie in Listing 6, die Beschreibung in den folgenden Abschnitten.<\/p>\n Listing 6: In einer Klasse gekapselter Zugriff auf die Meldungstexte<\/p>\n Damit die Eigenschaften der Klasse öffentlich zugänglich sind, muss diese zunächst deklariert und instanziert werden, was die folgende, in einem Standardmodul gespeicherte Zeile erledigt:<\/p>\n Beim ersten Zugriff auf eine Eigenschaft oder Methode der Klasse wird dann die Ereignisprozedur Class_Initialize <\/b>dieser Klasse ausgeführt. Diese instanziert die im Kopf der Klasse deklarierte und weiter oben beschriebene Klasse Messages<\/b> und sorgt damit für die Ausführung des Class_Initialize<\/b>-Ereignisses der Messages<\/b>-Klasse, was zum Füllen des Disconnected Recordsets <\/b>führt.<\/p>\n Von diesem Moment an kann man mit dem folgenden Aufruf auf die Meldungstexte des Disconnected Recordsets <\/b>zugreifen und erhält die passende Ausgabe:<\/p>\n Was geschieht<\/p>\n Wenn Sie diesen Aufruf absetzen, löst dies die Property Get<\/b>-Routine MsgText <\/b>der Klasse ConfigData <\/b>aus. Diese greift dann auf die Eigenschaft Source des Objekts m<\/b> zu, das ja eine Instanz der Klasse Messages <\/b>ist und einen Verweis auf das Disconnected Recordset <\/b>liefert.<\/p>\n Dabei wird – sofern dies nicht in einem vorherigen Aufruf schon geschehen ist – in einer Art Kettenreaktion nun auch die Klasse Messages <\/b>instanziert und das Disconnected Recordset <\/b>mit den gewünschten Daten gefüllt.<\/p>\n Die Routine MsgText <\/b>filtert dann das Recordset und gibt, sofern vorhanden, den zum übergebenen MsgFlag <\/b>passenden MsgText <\/b>zurück. <\/p>\n Sofern gewünscht, kann man das Objekt mit folgender Anweisung aus dem Speicher entfernen:<\/p>\n Mit diesen beiden Klassen haben Sie bereits das Werkzeug für den komfortablen Zugriff auf die Daten von Disconnected Recordsets <\/b>zur Hand.<\/p>\n Beispielhaft<\/b><\/p>\n Das Formular Demonstration Disconnected Recordsets <\/b>aus der Beispieldatenbank zeigt drei verschiedene Zugriffsarten auf die Daten einer Konfigurationstabelle: per DLookup<\/b>, per Recordset wie in Listing 3 beschrieben, und per Zugriff auf ein Disconnected Recordset<\/b>.<\/p>\n Um die bisherigen Ausführungen besser zu verstehen, schauen Sie sich einfach einmal die enthaltenen Listings und ihren Ablauf an; am besten setzen Sie dazu einen Haltepunkt in die Prozedur cboMsgFlag_AfterUpdate<\/b>, die beim Auswählen eines der Beispiele des Formulars ausgelöst wird.<\/p>\n Damit Sie auch den kompletten Ablauf nachverfolgen können, sollten Sie die Datenbank zuvor einmal öffnen und schließen, damit das Disconnected Recordset <\/b>auf jeden Fall neu erzeugt wird.<\/p>\n Ausbaufähig<\/b><\/p>\n Möglicherweise greifen Sie im Laufe der Zeit auf mehr als eine Tabelle mit Konfigurationsdaten zu. In dem Fall können Sie die Klasse ConfigData<\/b> leicht ausbauen, indem Sie weitere Tabellen mit Konfigurationsdaten anlegen, neue Klassen im Stile der Klasse Messages <\/b>erstellen und passende Einträge an den entsprechenden Stellen der Klasse ConfigData <\/b>hinzufügen.<\/p>\n Das Erzeugen der Tabellen und Klassen erfolgt analog zur Tabelle tbl_sys_Messages <\/b>und zur Klasse Messages<\/b>. Wenn Sie etwa weitere Daten wie Fehlermeldungen oder SQL-Anweisungen in Disconnected Recordsets <\/b>speichern und darauf zugreifen wollen, fügen Sie zunächst eine passende Deklaration zur Klasse ConfigData <\/b>hinzu. Für Fehlermeldungen sähe dies wie folgt aus: <\/p>\n\n\n
Public Function OpenRecordSet_By_DAO() As DAO.RecordSet\r\n On Error GoTo ErrorHandler \r\n Dim db As DAO.Database\r\n Dim rst As DAO.Recordset \r\n Set db = DBEngine(0)(0)\r\n Set rst = db.OpenRecordset("tblStammdaten", dbOpenDynaset) \r\n If Not rst Is Nothing Then\r\n Set OpenRecordSet_By_DAO = rst\r\n End If \r\nExitCode:\r\n On Error Resume Next\r\n Set rst = Nothing\r\n Set db = Nothing\r\n Exit Function \r\nErrorHandler:\r\n MsgBox Err.Description, vbInformation, "OpenRecordSet_By_DAO"\r\n Resume ExitCode\r\nEnd Function<\/pre>\nPublic Function OpenRecordSet_By_ADO() As ADODB.Recordset\r\n On Error GoTo ErrorHandler\r\n Dim rst As ADODB.Recordset \r\n Set rst = New ADODB.Recordset \r\n With rst\r\n Set .ActiveConnection = CurrentProject.Connection\r\n .CursorLocation = adUseServer\r\n .CursorType = adOpenDynamic\r\n .Source = "tblStammdaten"\r\n .Open\r\n End With \r\n If Not rst Is Nothing Then\r\n Set OpenRecordSet_By_ADO = rst\r\n End If \r\nExitCode:\r\n On Error Resume Next\r\n Set rst = Nothing\r\n Exit Function \r\nErrorHandler:\r\n MsgBox Err.Description, vbInformation, "OpenRecordSet_By_ADO"\r\n Resume ExitCode\r\nEnd Function<\/pre>\n
rst.Open [Source],
[ActiveConnection], [CursorType], [LockType], [Options]<\/pre>\n\n ![\"pic001.tif\"](\"..\/fileadmin\/_temp_\/2007_01\/DisconnectedRecordsets-web-images\/pic001_opt.jpeg\")
\n <\/div>\n\n
„Disconnected Recordsets“<\/b><\/p>\nSet .ActiveConnection = Nothing<\/pre>\n
.CursorLocation = adUseClient<\/pre>\n
.LockType = adLockBatch<\/pre>\n
„Disconnected Recordsets“<\/b><\/p>\n\n
Zieldefinition<\/b><\/p>\n\n ![\"pic002.tif\"](\"..\/fileadmin\/_temp_\/2007_01\/DisconnectedRecordsets-web-images\/pic002_opt.jpeg\")
\n <\/div>\n\nPublic Function fn_app_MessageText(MsgFlag As String) As String\r\n On Error GoTo ErrorHandler \r\n If MsgFlag = vbNullString Then GoTo ExitCode \r\n Dim rst As ADODB.Recordset\r\n Set rst = New ADODB.Recordset\r\n With rst\r\n Set .ActiveConnection = CurrentProject.Connection\r\n .CursorLocation = adUseClient\r\n .CursorType = adOpenForwardOnly\r\n .Source = "SELECT MsgText FROM tbl_sys_Messages WHERE MsgFlag = '" _
& MsgFlag & "'"\r\n .Open \r\n If Not rst Is Nothing Then\r\n If Not (.EOF And .BOF) Then\r\n fn_app_MessageText = !MsgText\r\n Else\r\n fn_app_MessageText = vbNullString\r\n End If\r\n End If\r\n End With \r\nExitCode:\r\n On Error Resume Next\r\n Exit Function \r\nErrorHandler:\r\n MsgBox Err.Description, vbInformation, "fn_app_MessageText"\r\n Resume ExitCode\r\nEnd Function\r\nDim Result as String\r\nResult = fn_app_MessageText("MeinMessageFlag")\r\nDebug.Print Result<\/pre>\nPrivate Sub Class_Initialize()\r\n On Error GoTo ErrorHandler\r\n Dim rst As ADODB.RecordSet\r\n Set rst = New ADODB.RecordSet\r\n With rst\r\n Set .ActiveConnection = CurrentProject.Connection\r\n .CursorType = adOpenStatic\r\n .CursorLocation = adUseClient\r\n .LockType = adLockReadOnly\r\n .Source = "SELECT MsgFlag, MsgText FROM tbl_sys_Messages"\r\n .Open , , , , adCmdText\r\n If Not rst Is Nothing Then\r\n Set .ActiveConnection = Nothing\r\n End If\r\n End With\r\nExitCode:\r\n On Error Resume Next\r\n Exit Sub\r\nErrorHandler:\r\n MsgBox Err.Description, vbInformation, "Class:Messages"\r\n Resume ExitCode\r\nEnd Sub<\/pre>\n
Private Sub Class_Terminate()\r\n On Error Resume Next\r\n rst.Close\r\n Set rst = Nothing\r\nEnd Sub<\/pre>\n
Public Property Get Source() As Object\r\n Set Source = rst\r\nEnd Property<\/pre>\n
Private m As Messages 'm = Meldungstexte\r\nPrivate Sub Class_Initialize()\r\n Set m = New Messages\r\nEnd Sub\r\nPublic Property Get MsgText(MsgFlag As String) As String\r\n On Error GoTo ErrorHandler\r\n If MsgFlag <> vbNullString Then\r\n With m.Source\r\n .Filter = "MsgFlag = '" & MsgFlag & "'"\r\n If Not (.EOF And .BOF) Then\r\n MsgText = Nz(!MsgText, vbNullString)\r\n Else\r\n MsgText = vbNullString\r\n End If\r\n End With\r\n End If\r\nExitCode:\r\n Exit Property\r\nErrorHandler:\r\n MsgBox Err.Description, vbInformation, "ConfigData:MsgText()"\r\n Resume ExitCode\r\nEnd Property<\/pre>\n
Public cd As New ConfigData<\/pre>\n
Debug.Print cd.MsgText("Autor")\r\nUwe Ricken<\/pre>\nSet cd = Nothing <\/pre>\n
Private e As ErrorMessages 'Fehlermeldungen<\/pre>\n
![\"pic003.tif\"](\"..\/fileadmin\/_temp_\/2007_01\/DisconnectedRecordsets-web-images\/pic003_opt.jpeg\")
<\/p>\n