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

Hi Leute!

Mit SQL-Statements recordsets versorgen, row-/recordsources zu befüllen, Tabellen/Datensätze zu bearbeiten und ähnliches ist ja kein Thema.

Aber irgendwie habe ich noch keine Lösung gefunden, VBA-Variabelen mit dem Ergebnis einer SQL-Afrage zu bestücken (wenn man von dem Umweg über ein Recordset absieht).

Schlichtes Beispiel die Sum Abfrage als SQL-Statement (die Abfrage an sich ist nicht das Thema), gibt es dazu eine Lösung wie ich nun das Ergebnis so direkt wie möglich (soll heissen mit so wenig Umwegen wie möglich, am besten gar keine Umwege ^^) in eine VBA-Variabele einlese?

Ja klar, ist die DSum Funktion, ich wollte aber wissen ob es eben die Variante gibt SQL-Abfrage in VBA-Variabelen direkt einzulesen (ohne Umwege über DSum und Co).

Bitte auch abgesehen von Funktionen wie die folgende:

Code:

Oder geht es tatsächlich nur über Umwege wie jetzt im obigen Beispielcode?

Irgendwie suche ich ja noch einer Lösung wie:

Dim lngCheck As Long

lngCheck = Ergebnis("SELECT SUM(MeinWert) FROM tblMeinTable WHERE Kriterium = 'MeinKriterium'")

Also ganz simple.

Gibt es sowas?

Gruß

Rainer

:)

 

Irgendwie wird die Verbindung zur Datenbank entstehen müssen. VBA weiß gar nicht, was eine Datenbank ist. *Smilie

Kürzestmöglich (aber auch ekligst):

Code:

 

Warum erstellst du dir nicht einfach eine passende Funktion? *Smilie

Ich nutze z. B. so etwas:
Code:

Eine ähnliche Funktion habe ich dann auch noch für ADODB und Zugriff auf das jeweilige DBMS.

Anwendung:
Code:

@Martin: so ist es sogar noch "kürzer" als über Currentdb.Openrecordset - zumindest auf Basis der Zeichenanzahl des Aufrufs. *biggrin.gif*

 

Dank Euch Beiden für die Antworten.

@ Artrus

Die kannte ich schon und gebe Dir auch absolut Recht ... ekligst. *wink.gif*

@ Josef P.

Mache ich ja auch - siehe oben - aber ich dachte vllt jibbet da noch was anderes was ich bis jetzt nicht kenne und das für seltenere Abfragen taugt. Für die häufigeren Abfragen würde ich dann die Schnelligkeit des Syntax aus meinem obigen Beispielcode bevorzugen.

Naja, hätte ja eigentlich wissen sollen das man nicht nach Abkürzungen suchen soll. *g*

Hat sich mit Euer beider Posts dann auch erledigt, weil wenn es was gäbe wüsstet ihr Beiden es ja auf jeden Fall. *wink.gif*

Gruß

Rainer

 

Wo ist dein Aufruf schneller als der von mir gezeigte Code?
Meinst du wegen DbEngine(0)(0)?
Den Code ..OpenRecordset(strSQL, dbOpenForwardOnly)(0) vermeide ich wie die Pest, da das dann jedesmal kracht, wenn kein DS vorhanden ist. (Anm.: Ich arbeite während der Entwicklung immer mit der Einstellung "Bei jedem Fehler unterbrechen".)
Außerdem ist die Zeit für das Speichern der Referenz zu vernachlässigen - daher verwende ich lieber Code, der zu keinem Fehler führt und verzichte auf das Programmieren mit Fehlern.
Und sollten diese paar Nanosekunden einen merkbaren Geschwindigkeitsvorteil bringen, dann musst du diesen Aufruf in einer Schleife einsetzen - dann stellt sich für mich aber wieder die Frage, ob der Code nicht mit einem Recordset mit den notwendigen Filterbedingungen für die gesamte Schleife und anschließendem Durchlaufen der Datensätze besser wäre.

Falls du mit Schnelligkeit das Schreiben des Code meinst:
Was hindert dich daran, mehrere Funktionen dieser Art zu nutzen? *wink.gif* ... die lassen sich sogar nett ineinander verschachteln, damit man bei Änderungen nur an wenigen Stellen schrauben muss.

Code:

 

\@ Josef P.

Nun ja ... wir reden hier nicht von Nanosekunden (der benötigte Zeitbedarf für die Referenzierung ist enorm, wirklich enorm), sondern von rd. 50% Zeitvorteil. Was bei einem Zeitverbrauch mit currentDb Aufruf von 60 - 70 Millisekunden im vergleich zu dem Aufruf über DBEngine mit nur rd. 30 Millisekunden bei der Verarbeitung von größeren Datenmengen oder Aneinanderreihung von mehreren Aktionen dieser Art schon einen enorm spürbaren Unterschied für den User vorm PC machen kann (hab die ganze Palette mal durchgemessen ... angefangen von DLookup, über FLookup mit CurrentDB und FLookup mit DBEngine ... ist wirklich enorm). Zumindest auf die reine LookUp Variante ausgemessen (Test lief auf Tabelle mit rd. 1000 DS und mit rd. 1.500 DS).

Natürlich, wenn es den gleichen Vorgang zigtausendmal zu wiederholen gibt dann wäre es nicht wirklich sinnvoll über so eine Funktion zu arbeiten sondern dann mit einem einmal geöffneten recordset. Aber kann ja bei mehreren ineinander verschachtelten Aktionen durchaus mal vorkommen das da 10 mal der Aufruf vorkommt und da finde ich dann eine Zeitersparnis von 300 Millisekunden enorm ... zumal der User ja solche Zeitspannen bereits spürt.

Klar kracht der Code wenn es keinen DS gibt, deswegen ja auch im Error-Handler die Behandlung des Fehlers 3021 (genau der Krachpunkt). Aber genau dafür sind doch Error-Handler da, zumindest meine Meinung. *g*

Die Einstellung nutze ich nicht während der Entwicklung. Schreibe den Error-Handler eh erst nach testen der Funktion rein und sollten danach fehler auftreten werden Dir mir ja schön brav in einer Tabelle eingetragen (okay, das kannste nicht sehen da der Error-Handler im obigen Code ja nur den Aufruf der Prozedur beinhaltet).

Dazu muß man sagen - obwohl mühselig und während der Entwicklung manchmal nervend - programmiere ich nach der Test-Driven-Development-Idee, jede Prozedur wird in Einzelschritten erstellt und jeder Einzelschritt wird getestet bevor der nächste Schritt drankommt.

Aber gut, wären wir wieder beim Thema jeder hat seine eigene Art und Weise ... was meinst Du wieviel Spot ich mir schon für meine persönliche Art der "Codegestaltung" anhören durfte. Aber wenigstens hat sich noch keiner über Unlesbarkeit beschwert. *lach*

Gruß

Rainer

 

.. und in welchem Verhältnis sehen diese paar Millisekunden zur Recordset-Auswertung? 50% (Bei CurrentDb vs. DbEngine(0)(0) können das sogar 90% werden) hört sich super an, ist aber Verhältnis mäßig wenig im Vergleich zur Datenabfragezeit. Natürlich ist es vorteilhaft mit CurrentDb nicht jedesmal eine neue DB-Instanz zu holen, aber bitte nie die absolute Zeitersparnis vergessen. (Bei Test, die ich vor einigen Jahren durchführte, lag das unter 1 ms.)
Ich sehe nicht zu selten, dass unter VBA alle möglichen Optimierungen getroffen werden, die Datenbanktechnik aber der größte Mist ist. Und dann wird behauptet, mit Access kann man keine schnellen Anwendungen schreiben, da ja VBA bereits ausgereizt wurde.

BTW: guck noch mal in den Code von mir aus Beitrag #3, ob du CurrentDb findest. *wink.gif*

Code:

Und du bist der Meinung, diese Variante ist um vieles langsamer, nur weil die Referenz einmal gespeichert wird und mit EOF geprüft wird?

 

Ähm, da muss ich mich mal dazwischen werfen. Nein, dafür sind Err-Handler nicht gedacht. Ein Errorhandler soll die Fehler abfangen, die auftreten, wenn dein Code sauber ist und nicht zur Erzeugung von funktionieremden Code dienen. Oder verwendest du im Err-Handler jedesmal ein Select Case um unbekannte und bekannte Fehler zu unterscheiden?

Und die größte Fehleinschätzung ist, dass je weniger Zeilen Code man braucht, die Verarbeitungsgeschwindigkeit steigt. Es wird einzig und allein kryptischer.

 

Hihi,
da habe ich mal einen guten Vergleich gehört:

Alles mit On Error laufen lassen sei etwa so, als führe man blind mit dem Auto querfeldein und evaluiert die Fehler, wenn es nicht mehr vorangeht: "Baum im Weg".

Besser sei es doch, nach vorne zu gucken und zu schauen, wo man langwill. Klar, da sieht man nicht, wenn sich bei 180 der Motor verabschiedet haben sollte, aber das wäre dann wirklich ein Fall für einen Fehlerfänger...

 

\@ Josef

Oops ... das CurrentDBC hatte ich doch glatt übersehen. Bin halt nicht so sehr auf DAO eingeschossen, ein ADODB open mit cnn ohne vorherige Referenzierung der Connection wäre mir dagegen gleich aufgefallen. ^^

So nehme ich natürlich alles zurück und behaupte das Gegenteil. *g*

@ J_Eilers

Hatte ich auch nie irgendwo behauptet das je kürzer der Code desto schneller die Geschwindigkeit. War nie mein Tenor. *wink.gif*

Und zum Thema Error-Handler ... ja tue ich, jeder Error-Handler hat ein Select Case zur Auswertung der Fehler, bzw. Weiterleitung von nicht erwarteten Fehler an den globalen Error-Handler der diese dann protokolliert und entsprechend der schwere des Fehlers weitere Aktionen durchführt. Ich dachte das macht jeder? *g*

Und auch beim sauberen Code gibt es immer Fehler - vor allem Eingabefehler und Handlingsfehler vom User. Man kann sie direkt im Code abfangen oder eben erwartete Fehler über den Error-Handler mit Select-Case abarbeiten.Wobei ich die Abarbeitung von erwarteten Fehlern im Error-Handler mit Select Case als "sauberer" empfinde ... aber wie gesagt reines persönliches Empfinden.

Gruß

Rainer

 

\@ Artrus2711

Och ... ich kenne solche Vergleiche andersrum: Wer der Meinung ist das er ohne saubere und vor allem wirklich konstante Fehlerbehandlung programmieren kann, der kann sich gleich als Hellseher betätigen und wird wohl mit einer Kristallkugel anstatt mit einer Tastatur programmieren.

Der stammt nicht von mir und natürlich nur sinngemäß und nicht wortwörtlich zitiert.. *wink.gif*

Sorry, aber egal wieviel vorrausschauenden Fehlerabfang (Validierung von Eingaben u.ä.) ich eingebaut habe in Anbetracht das ich auf invalidate bei den Ribbons aufbaue und ich vor habe meine Anwendung als Runtime weiter zu geben wird noch nichtmal eine einzeilige Prozedur ohne Fehlerbehandlung (okay, da dann natürlich nicht mit Select Case Auswertung sondern schlicht On Error Resume Next) rausgehen. *wink.gif*

Gruß

Rainer

 

Ok, das kann ich nachholen. *Smilie
Code:

Auf CurrentDbConnection.ADODB will ich jetzt nicht näher eingehen - nur soviel: das ist meine Kapselung für ADODB-Zugriffe. *wink.gif*

Ich versuche Fehler immer zu vermeiden statt sie später abzufangen. *wink.gif* .. Was natürlich eine ordentliche Fehlerbehandung für die nicht vorhergesehen Fehler nicht vermeidet.
Wenn ich z. B. im Code einen Wert in einem Datenfeld erwarte, prüfe ich das vor der Verwendung und warte nicht, bis die Ausführung der damit zusammengesetzten SQL-Anweisungen einen Fehler wirft.
Aber wie du schon geschrieben hast: es gibt unterschiedliche Programmierstile. *Smilie

 

\@Raist:
Steig doch um auf VB.Net. Da kannst du das ganze Programm als Try-Catch-Finally laufen lassen. *yelrotflmao

Wenn schon die Variablendeklaration ein Crash and burn wirft, weißt du, dass du ein Problem hast. *Smilie

 

Für mich ist sauber den User auf seine Fehler hinzuweisen und Ausnahmefehler zu protokollieren und zu dokumentieren. Meine Anwendungen besitzen auch Err-Handler und erzeugen daraus ErrLogs und versenden mir diese bei Bedarf. Aber vielleicht hilft ja ein Vergleich:

Code:

Ist für mich umständlicher und nich eindeutig im Gegensatz zu diesem:

Code:

Ja die 2. Version benötigt mehr Zeit bei der Erstellung, dafür kann ich im Vorfeld bereits Fehler ausschließen.

 

\@ Josef

Interessant ... das gucke ich mir näher an. Natürlich nur wenn Du nichts dagegen hast. *wink.gif*

@ J_Eilers

Wieso diskutieren wird dann? Sind wir uns ja einig. *wink.gif*

Ausser das ich für eine Function die ich selber aus meinem Programmcode aufrufe und in einigen Fällen damit rechnen muss und auch will (manchmal will man ja prüfen ob bereits Einträge in Tables da sind oder eben nicht) das die Rückgabe "leer" ist, diese Fälle dann doch einfacher über den Err_Handler abfange. *wink.gif*

Gerade weil ich in Hilfsroutinen von denen der User i.d.R. nichts mitbekommt nicht unbedingt Meldungen einbauen will. Die baue ich dann lieber in der aufrufenden Prozedur ein ... wie eben, wenn ein leeres Feld gelesen wird (der Err-Handler greift und damit Flookup nur Null zurück gibt) und ich nicht will das das Feld leer ist, dann spult die aufrufende Routine die Meldung ab. Die Prüfung der übergebenen Werte läuft natürlich auch in der Hauptroutine ab (eben isnumeric, isdate o.ä. nötiges).

Also, sind wir uns doch einig. *g*

@ Artrus

Stimmt, hast Recht ... wäre eine Möglichkeit. *lach*

Gruß

Rainer