Office: (Office 2007) SQL-Abfrage direkt in VBA-Variable?

zu FLookup:
Ich verstehe immer noch nicht, was an der Variante mit ..OpenRecordset(..)(0) besser sein soll als an der Verwendung der Recordset-Referenz.
Die Laufzeit kann es nicht sein, denn die Unterschiede zwischen den beiden Varianten sind nicht einmal eindeutig messbar.
Was spricht also gegen die Variante mit der Recordset-Referenz?
Die paar Zeilen Code mehr, die man einmalig in die Funktion schreibt?
Für mich ist das Code, der klar erkennbar einen Fehler auslöst, obwohl dieser einfachst vermieden werden könnte.

Anm.: die Variante mit OpenRecordset(..)(0) lass ich mir ja noch eingehen, wenn man sie in einem beliebigem Code-Abschnitt verwendet, um direkt die Daten aus einem sicher vorhandenen DS zu holen, aber nicht in einer Hilfsfunktion, die man nur einmal erstellt und die die Aufgabe hat, genau diesen Zugriff zu vereinfachen.

 

\@ Josef P.

Doch, die Unterschiede sind meßbar zumindest auf meinem Rechner.

Ich habe das Ganze allerdings mit ADO durchgespielt, selbst wenn bereits auf eine geöffnete ADO-Connection zugegriffen werden kann liegt der Unterschied zur Variante mit DBEngine bei satten 50% oder knapp 30 Millisekunden zu 60 Millisekunden (DLookUP irgendwas um die 180 Millisekunden).

Das kann aber nicht nur an meinem Rechner liegen, sondern muß allgemein gültig sein.

Bin ja nicht von selber drauf gekommen das nach zu messen, sondern habe den Tip aus einem Buch von André Minhorst. Nachgebastelt und selber gemessen komme ich eben auf obige Ergebnisse.

Wie gesagt, bei bereits bestehender Connection für das ADODB-Recordset.

Gruß

Rainer

 

Vergleichst du da gerade Äpfel mit Birnen? Natürlich ist DBEngine auf die aktuelle Jet-DB schneller als die ADODB-Variante.

Zu Sicherheit: mir geht es nicht um den Vergleich zw. den Dxx-Funktionen und den Recordset-Ersatz-Funktionen sondern um den Unterschied zw.
Code:

und
Code:

Ich kann dabei weder mit DAO noch mit ADODB einen Unterschied messen. (Je nach Lust von VBA ist mal die eine - später die andere Variante schneller ... anders formuliert: die Differenzen liegen innerhalb der Messtoleranzen. ... du weißt ja: wer misst, misst Mist. *wink.gif*)


BTW: wie hast du unter ADODB diese Zeile
Code:

umgesetzt? .. mittels:
Code:

 

Gebe natürlich zu das ich bei meinen Tests das ADODB.Recordset im klassischen Sinne angesprochen habe:

Code:

So meine ich das ich das aufgebaut habe.

Gruß

Rainer

 

Ok, dann nimm diesen Code mit direkter Verbindung zu einer SQL-Server-DB und vergleiche ihn mit der DBEngine-Variante auf die verknüpfte Tabelle. ... dann wird vermutlich die ADODB-Variante schneller sein.

Dass DbEngine(0)(0).OpenRecordset(...)(0) verglichen mit dem Öffnen eines ADODB-Recordsets auf die aktuelle Jet-DB schneller ist, ist klar. Das hat aber nichts mit dem Zugriff auf das Datenfeld über OpenRecordset(...)(0) vs. rst.Fields(0) zu tun. *wink.gif* ... so etwas darf man nur mit der gleichen Zugriffstechnik vergleichen. Sonst vergleicht man nicht den Feldzugriff sondern die Öffnungszeit für die unterschiedlichen Recordset-Varianten.

 

\@ Josef P.

Darum ging es ja im Prinzip auch, um die Öffnungszeiten der verschiedenen Möglichkeiten so eine Abfrage zu gestalten.

Aber letztendlich hat es mich ja zum Ziel gebracht, die Variante die ich nutze ist ja gleich schnell wie Deine Variante. Einziger Unterschied ich brauche noch den Err_Handler dazu den Du durch den Einsatz des Recordsets vermeidest.

Aber auch gut ... hast mich zum Nachdenken gebracht ob ich die Function nicht schnell ändere. Hat ja schließlich so seine Vorteile wenn man immer so programmiert das oben x rein kommt und unten y raus kommt, dann kann man das was dazwischen passiert ja problemlos ändern. ^^

Wenn ich die aktuelle Story abgearbeitet hab, dann werde ich mir diesen Thread nochmal genauer angucken.

Auf jeden Fall Danke für den Schubs in die Richtung. *wink.gif*

Gruß

Rainer

 

Ich nutze trotzdem eine Fehlerbehandlung in meinen Prozeduren, auch wenn ich sie meisten entferne, wenn ich den Code in einen Beitrag schreibe, damit sie nicht vom eigentlichen Programmcode ablenkt.
Der Unterschied ist nur, dass in dem von mir gezeigten Beispiel die Fehlerbehandlung nicht zum Logikteil der Prozedur gehört sondern nur für die Ausnahmefehlerbehandlung dient, um z. B. Fehler im SQL-Code u. ä. abzufangen, welche aber bei ordentlicher Programmierung nicht auftreten sollten. *wink.gif*


Ich erstellte eine Test-Anwendung für den Vergleich der Varianten:

 

Ich hätte auch noch Ergebnisse nachzureichen:

Code:

DlookUp kennt jeder, hier die anderen beiden Versionen:

Code:

Lokal waren es 100.000 Durchläufe übers Netzwerk nur 1000. Ja Josef ich weiß, in der Hilfe steht, dass man DBEngine nicht verwenden soll. Es ist mir immer noch Unbegreiflich, warum man das nicht machen soll. Aber die Hilfe ist seit A97 auch beständig schlechter geworden (meine Empfindung).

 

\@Jan: geht es dir um Mikrosekunden? ... dann nimm CurrentDbC statt DBEngine(0)(0), denn das ist nach der ersten Initialisierung schneller. *biggrin.gif*
Was habe ich nun für einen Vorteil, wenn ich DBEngine(0)(0) verwende? Einerseits ist es langsamer als CurrentDbC und andererseits von MS nicht empfohlen. Ich finde zumindest für mich keinen Grund es zu verwenden.

Der Grund warum die CurrentDbC-Variante schneller ist, ist schnell erklärt: es wird nur eine Referenz geprüft und nicht in 2 Containern nachgeschlagen.

 

\@Josef Optimierung braucht man öfters unter Access eher weniger, aber solche Vergleiche sind manchmal einfach interessant. Und ich habe nicht CurrentDbC mit DBEngine verglichen, sondern DLookUp, fLookUp und OpenRecordset()(0). Und das sowohl in einer lokalen Tabelle, als auch übers Netzwerk.

Den Hinweis bezüglich DBEngine habe ich nur gebracht, um dieser Diskussion aus dem Weg zu gehen. *wink.gif*

 

\@Jan: Ich interpretierte deinen Text so, dass DBEngine(0)(0) die beste Wahl sei, daher erlaubte ich mir auf CurrentDbC hinzuweisen. *wink.gif*

Zur Vergleichsmessung:
Bei einer verlinkten Tabelle aus einem lokalem BE kann ich keinen merkbaren Unterschied zw. OpenRecordset(...)(0) und der Recordset-Referenz-Variante feststellen. (Dass Dlookup langsamer ist, ist nicht ungewöhnlich - man muss sich nur den Showplan davon ansehen. *wink.gif*)
Interessant finde ich, dass bei dir übers Netzwerk OpenRecordset(...)(0)-Variante anscheinend eindeutig langsamer ist als die Variante mit der Rs-Referenz.

Hier mal eine Messreihe von mir (verknüpfte Tabelle aus lokalem BE):
1 = OpenRecordset(...)(0)
2 = Mit Recordset-Referenz
Code:

Ausschlaggebend für die Abweichungen dürfte die Ungenauigkeit der Messung sein, sonst würde immer eine Variante die schnellste sein. (Ich messe über eine Klasse und QueryPerformanceCounter)

Meiner Ansicht nach dürfte die Zugriffsart auf den Feldwert nicht vom Ort des BE abhängig sein, da zu diesem Zeitpunkt das Recordset bereits geöffnet ist. Wenn es doch so aussieht, könnte das möglicherweise auch andere Gründe haben. => ich würde daher die Recordset-Referenz-Variante nicht aufgrund der Geschwindigkeit empfehlen, sondern aufgrund des für mein Empfinden besseren Codes. *Smilie

 

\@Josef Nein, das war nicht meine Absicht. Wenn ich sage, dass ich übers Netz zugreife, wirds wohl auch ein Netzlaufwerk sein (Sorry bin grad ziemlich gereizt). Die Schwankungen darin spielen natürlich eine Rolle. Auch meine Tabelle ist mit 40K Daten deutlich größer als deine (ich habe dein Beispiel angesehen). Wie es sich mit einer Indexsuche vs. Textsuche verhält, wäre auch noch interessant. Mit deinem Mist messen hast du recht und deswegen sind die 7 Sekunden auch entsprechend relativ zu sehen.

 

hm .. das dürfte imo keine Auswirkungen auf den Feldzugriff haben, sondern nur mit dem Öffnen des Recordsets zusammenhängen. Für den Vergleich zw. DLookup & Co. ist das auf jeden Fall interessant, aber für den Vergleich zw. OpenRecordset(...)(0) und Recordset-Referenz müsste das egal sein. Aus diesem Grund nahm ich bei meinem Test extra eine Tabelle mit wenigen DS und ging über den PK, damit der Anteil der Zeitmessung für die Datenauswertung so klein wie möglich bleibt.