Office: Listbox per QDF füllen

\@Anne
@CptChaos

In einer Anwendung von mir läuft

strMySQL= "...."
DB.QueryDefs("qryMySQL").SQL = strMySQL
problemlos. qryMySQL ist die Recordsource eines SubForms.

Werden die Parameter in die Abfrage strMySQL eingearbeitet und diese in der
Querydef("qryMySQL").SQL gespeichert müßte das doch gehen. Vorausgesetzt die Datumsabfragen sind richtig formuliert.

Wolfgang

 

Hallo!

.. dann ist das eine normale SQL-Anweisung für eine Abfrage mit fixen (in der SQL-Anweisung stehenden) Filterwerten und keine Parameterabfrage mehr.

Wenn du diese SQL-Anweisung in eine gespeicherte Access-Abfrage (QueryDef) übernimmt, hast du eine Access-Abfrage mit fixen Filterwerten. In dieser Abfrage kannst du dann natürlich keine anderen Parameterwerte mehr übergeben.
Für andere Werte muss die SQL-Anweisung neu definiert (zusammengesetzt) werden.

mfg
Josef

 

Hallo Josef!

Das verstehe ich jetzt nicht.
Ich kann doch die WHERE-Bedingungen(= die Parameter) einer Abfrage immer wieder
dynamisch zusammensetzen und dann einer Abfrage zuweisen.
Genau das tue ich in meinem Vorschlag.
Aber wir reden offenbar von verschiedenen Dingen.
Falls das so ist wirst Du mich sicher aufklären.

Wolfgang

 

Hi,

du meinst wahrscheinlich die Kriterien, Wolfgang - Bedingungen = Kriterien, Parameter sind etwas anderes.

 

Hallo Anne!

Kannst Du ein verständliches Besipiel posten, was Du unter Parametern verstehst?

Wolfgang

 

Hallo!

Ich versuche den Unterschied mit Code zu beschreiben. *Smilie

Ziel: Recordset öffnen, das gefilterte Datensätzen aus Tabelle "Tab123" enthält.
Filterkriterien: X = 5 und Y like 'a*'

Variante 1 (SQL-Anweisung dynamisch zusammensetzen und damit ein Recordset - über den QueryDef-Umweg öffnen):
Code:

Anm.: Dass hier der Weg über das Querydef nicht sinnvoll ist, soll für diesen Beitrag egal sein. *wink.gif*


Variante 2 (Parameterabfrage):
Code:

Die gespeicherte Parameterabfrage könnte z. B. so aussehen:
Code:

Falls du nun den Vorteil der Parameterabfrage suchst: Die Datentypen sind in der Abfrage definiert und sind somit typsicher.
=> Du musst im VBA-Code keine passende Konvertierung in Text durchführen, da du im VBA-Code keinen SQL-Text erzeugen musst => Wahrscheinlichkeit für Programmierfehler wird vermindert.

mfg
Josef

 

Hallo Josef!

Mit den Parametern wird also doch eine Where-Klausel gebildet.
Aber das nützt dem OP nichts, denn die Abfrage kann so
"select * from Tab123 where X = [FilterWertX] AND Y like [FilterwertY]"
keine Datenquelle sein, *ohne* daß die Parameter per Tastatur eingegeben werden müssen.
Also bleibt nur übrig die Where-Klausel ohne Parameter auszuformulieren
(where X = 235 and Y like '*abcde*') **und** als Datenquelle zu speichern.
Eben mit QD.SQL = "MeineAbfrage"
Und das sooft ich sie eben abgewandelt benötige.

Frage:
set OpenTab123Recordset = qdf.OpenRecordset
kann so als Datenquelle für ein Kombifeld oder ein Formular fungieren?
Ist mir neu.

Wolfgang

 

Hallo!

Wie meinst du das?

Wie die Parameter-/Filter-Werte in der Anwendung landen ist egal. Sie werden in beiden gezeigten Prozeduren per Code zum Filtern aufbereitet - in dem Sie als Prozedur-Parameter übergeben wurde.
Ich dachte das kann man sich mit dem gezeigten Code einigermaßen vorstellen.

BTW:
Ich schrieb bei der Abfrage übrigens
Code:

und nicht nur
Code:

.. das ist ein großer Unterschied, da im ersten Fall der Datentyp festgelegt ist. Die 2. Variante ist "Programmieren auf gut Glück".

Den Set-Ausdruck kannst du nicht verwenden. *biggrin.gif*
Du kannst aber ein Recordset als Datenquelle einstellen.

Im Anwendungfall könnte es dann so aussehen:
Code:

mfg
Josef

 

Ja, siehe #4

 

Hallo Marsu

Set Me!lstResult.Recordset = qdf.Openrecordset(dbOpenSnapshot)

Das habe ich, so sieht es jetzt aus, überlesen.
Dies so als "Datenherkunft" in ein Form/Kombifeld/Listbox einzutragen geht ja nicht.

Ich habe in etlichen Anwendungen die Festlegung einer Abfrage mit QD.SQL=... für Forms/Kombifelder/Listboxen verwendet. Dies hat das im OP beschriebene Problem noch nie ausgelöst. Und der Code ist nicht wirklich umfangreicher und auch nicht unverständlicher. Wieder einmal Geschmackssache.

Wie merkwürdigerweise die meisten Fragen, die in diesem Forum gestellt werden, mir in meinen Anwendungen noch nie begegneten, obwohl ich Access seit der Version 2.0 verwende.

Wolfgang

 

[unabhängig vom Bedarf im aktuellen Thread:]

Meist ist das, was man selbst verwendet, verständlicher als anderes. *wink.gif*
Das muss aber nicht zwangsweise immer die "sauberere" Lösung sein.

Betrachte bitte einmal die folgenden Blöcke:
Code:

vs.

Code:

Ich erkenne im 2. Block schneller, wie die Variablen FilterWertX und FilterWertY verwendet werden.

Parameterabfragen werden meiner Meinung nach viel zu selten eingesetzt.
Schau mal wie oft es hier im Forum Probleme beim Zusammenstellen eines String gibt, der später als SQL-Anweisung verwendet werden soll.

Gerade für Programmier-Anfänger finde ich es sicherer, sich mit Parameterabfragen zu beschäftigen, da man sich als Entwickler keine Gedanken über die richtige Konvertierung von Werten in Text machen muss, sobald man den Datentyp im Abfrage-Parameter definiert hat.
=> und das was gut für Programmieranfänger ist, ist auch gut für "erfahrene Programmierer", da so etwas Schlammpigkeitsfehler vermeidet.

Kurz gefasst (und vielleicht etwas übertrieben formuliert: *wink.gif*)
Wenn man als Programmierer (mit Praxiserfahrung) in einer Prozedur mehr als 2 Sekunden nachdenken muss, was in der Prozedur abläuft, besteht Refactoring-Bedarf.

mfg
Josef

 

Neben Länge eines Codes und Verständlichkeit eines Codes gibt es noch weitere Einflussgrößen, die einen Entwickler interessieren könnten: Eine davon wäre das Thema "gespeicherte Abfrage".

Diese ist im Vergleich zu einer als String vorliegenden SQL-Anweisung schneller, weil Syntaxprüfung und Erstellung eines Ablaufplanes bereits erfolgt ist und kompiliert vorliegt, womit dann diese Schritte bei folgenden Abfrageausführungen nicht ausgeführt werden müssen.
Eine Parameterabfrage kann diesen Vorteil nutzen.

Wenn man in eine SQL-Anweisung Parameterwerte einbaut und daraus dann eine gespeicherte Abfrage erstellt, ist der Vorteil der Nutzung des vorhandenen Ablaufplanes für die erste Ausführung noch nicht vorhanden. Hier verbessert man nicht die Situation im Vergleich zu der direkten Zuweisung der SQL-Anweisung.

 

Hallo Josef!

Das hängt auch vom Gegenstand ab.

Aber wenn man das SQL-Geschreibsel so verfaßt wie es ebs17 in seinen Beiträgen tut, ist das Lesen der where-Klauseln auch kein Problem.

Aber etwas bleibt offen:
Warum gibt es dann das OP?
Eine solche Frage hat sich mir eben noch nicht gestellt.
Oft ist der etwas ausführlichere (um nicht zu sagen umständlichere) und vielleicht verständlichere Weg der sicherere. Zumeist für die Urlaubsvertretung.

Jemandem deswegen "unsauberen Code" vorzuwerfen ist anmaßend.

Stimmt. Aber zumeist weil der Fragesteller etwas tun möchte wozu er (noch) nicht befähigt ist. Ich war noch nie als Fragesteller wegen eines SQL-Strings hier!
So wie Du auch.

Wolfgang

 

Hallo Wolfgang

Als DatenSATZherkunft-Eigenschaft nicht.
Jedoch kannst du so das Recordset des Steuerelements direkt befüllen,
so dass es einer Zuweisung der Datensatzherkunft nicht mehr bedarf.

BTW:
Abfragemanipulation ala
Code:

braucht man m.A.n. nur für Berichte mit wechselnder Datenherkunft,
da hier eine direkte Zuweisung des Recordsets zur Laufzeit nur schlecht möglich ist.

 

Das beinhaltet nicht, dass alles andere unsauber ist. Daher sind Begriffe wie "anmaßend" unpassend.

Richtig ist aber, dass manche mit Access nicht mal nur so eine Verwaltung von drei Regalfächern mit 280 CD's ausführen, sondern es auch als Frontend zur Bedienung einer SQL Server/Oracle/DB2-Datenbank und dann im Mehrnutzer- und 24-Stundenbetrieb einsetzen.
Und da wird man sauber auch nach Kriterien wie universell, gleich einsetzbar in allen Konstellationen, kompatibel zu anderen Werkzeugen für Frontends beurteilen.

Ehe man sich also zu Beurteilungen hinreißen lässt, sollte man prüfen, ob man sich in einer vergleichbaren Entwicklerwelt befindet oder man sich zumindest in diese hineindenken kann.