Office: Openrecordset: 1 Parameter wurde erwartet ...

Hallo,

Miniproblem, denke ich, aber ich komme nicht drauf:

Code:

In der letzten Zeile kommt ein Laufzeitfehler 3061: 1 Parameter wurde erwartet, aber es wurden zu wenig Parameter übergeben.

Ich habe diesen Teil isoliert aus einer Funktion, in der ich erfolgreich schon 2 ähnliche Recordsets geöffnet habe. Ich habe auch schon dbOpenDynaset gegen dbSnapshot getauscht usw.

Ein Kopieren des Kriteriums in eine neue Abfrage (wie in entsprechenden anderen Diskussionen empfohlen) ist erfolgreich und liefert die gewünschten Ergebnisse. Es wird in der ursprünglichen Query nur 1 Feld, ID, zurückgegeben.

Auch ein Neustart mit Reparieren hat keine Änderung bewirkt (habe ich sonst schon bei einigen Problemen als Lösung gehabt).

Idee ?

Danke,
JR²

:)

 

Zeige mal die Abfrage qrySelectRedGroup (als SQL).
Die Fehlermeldung verweist auf einen Datentypfehler in einer WHERE-Klausel oder eine falsche Bezeichnung (Tippfehler?).

 

Hallo JR!

Ich schätze, dass liegt daran, dass in der Abfrage ein Kriterium auf ein Steuerelement in einem Formular Bezug nimmt.

Weitere Informationen findest Du hier:
donkarls Access-Seiten

HTH

 

Hallo Thomas,

Treffer, versenkt. Es gibt einen Bezug auf ein Formular.

Danke,
JR²

 

Interessanterweise hat es bei mir mit der EVAL-Funktion nicht geklappt, aber ich habe den Bezug auf das Formular in eine eigene Funktion verschoben, dann hat es funktioniert.

Gruß,
JR²

 

Hallo!

Du könntest den Formularbezug auch über eine Parameterzuweisung lauffähig machen.

Prinzip:
Code:

Damit würde die Abfrage weiterhin noch den Formularbezug ermöglichen.
Falls du den Formularbezug allerdings nur für die obigen Codeblock benötigst, würde ich eher auf einen allgemeinen Abfrage-Parameter umstellen, da ich sehr wenig von Formularbezügen in Abfragen halte (das macht die Abfrage nicht besonders flexibel einsetzbar).

mfg
Josef

 

Hallo Josef,

ich würde gerne kurz diese Zeile diskutieren wollen:
Code:

Hier verweist Du auf den ersten Parameter (0). Was aber, wenn zur Abfrage ein zusätzlicher Parameter hinzugefügt wird. Dann könnte es doch sein, dass der zusätzliche Parameter zum ersten Parameter wird. Die Gefahr, die ich dabei sehe ist, dass man nach der Änderung der Abfrage vergist, den Code anzupassen.
Außerdem finde ich Code, der Werte in Auflistungen über ihren Namen anspricht, generell lesbarer.

Wäre es daher nicht "besser", den Parameter generell über seinen Namen anzusprechen? In diesem Fall also:
Code:

CU

 

Hallo!

Ja, das wäre auf jeden Fall besser.

Wenn wir aber schon beim Thema sind:
Ich würde grundsätzlich überlegen, ob überhaupt ein direkter Formularbezug notwendig ist.
Ein Beispiel: ich verwende durchaus in Kombinationsfeldern einen Bezug zu einem Formular-Steuerelement, damit ich nicht per Code den Filter einstellen muss. Dabei nutze ich aber die Fähigkeit von Access, den Bezug auf die aktuelle Formularinstanz herzustellen, ohne Forms!FormularName zu verwenden.
Damit entsteht beispielsweise eine Abfrage, die folgendermaßen aussehen könnte:
Code:

Sobald nun im Formular ein Steuerelement mit dem Namen "txtXyz" existiert, wird die Abfrage funktionieren.
Vorteil: diese Variante funktioniert auch, wenn das Formular als Unterformular verwendet wird - oder wenn mehrere Instanzen des Formularsals HF geöffnet sind.

Hätte ich die Abfrage folgendermaßen gestaltet:
Code:

... könnte ich nur eine einzige Formular-Instanz verwenden.

mfg
Josef

 

Die ursprüngliche Frage bietet noch zwei weitere Diskussionsansätze:

1) In dem SQL-String könnte man statt qrySelectRedGroup die entsprechende SQL-Anweisung einbauen und dort den Parameter per VBA einbauen.
Nachteil: Man verliert den Performance-Vorteil einer kompilierten Abfrage. Den spüren viele aber nicht durch andere (zeitaufwändigere) Gestaltungen.
Vorteil: Das ist übersichtlich und flexibel.
2) Warum wird in einer Abfrage, die genau ein Feld zurück gibt, dieses Feld in einer weiteren Abfrage noch einmal ohne irgendwelche "Spezialanforderungen" abgefragt?

 

Hallo!

Wenn die SQL-Anweisung der Abfrage etwas komplexer ist, bezweifle ich, dass das übersichtlicher ist. *wink.gif*
Ich halte die Verwendung einer Parameter-Abfrage für übersichtlicher und weniger fehleranfällig als per VBA zusammengesetzte SQL-Anweisungen.
Wenn ich mir das ewige Problem mit dem Umwandeln von Datentypen zum Zusammensetzen von SQL-Anweisungen ansehe, verstehe ich sowieso nicht, warum das so gerne verwendet bzw. empfohlen wird.

/edit:
Bitte nicht falsch verstehen: ich habe nichts gegen per VBA zusammengesetzte SQL-Anweisungen, wenn man weiß was man tut. Ich verstehe nur nicht, warum Parameterabfragen so selten eingesetzt werden.

mfg
Josef

 

Nicht als Widerspruch, sondern nur eine Sichtweise:
Eine SQL-Anweisung ist nur etwas Text nach bestimmten Regeln (Reihenfolge Schlüsselwörter u.ä.). Einen Text kann man beliebig zusammensetzen (konstante Teiltexte und variable Teile) oder auch nachträglich ändern (Replace). Ein wenig muss man dabei das Handwerkszeug beherrschen (Wissen, wie das Ergebnis aussehen soll + Ansehen, was man erzeugt).

Das traue ich aber denjenigen, die ein Problem wie das eingangs angefragte haben, regelmäßig eher zu als das richtige Platzieren und Bestücken von Parametern in einer Abfrage.

Ein Parameter für eine gute Lösung ist auch, dass man (der anwendende Entwickler) die Lösung so versteht, dass er sich dabei "wohlfühlt", auch bei der möglichen Anforderung einer Anpassung. Immerhin werden gerne Tabellen zeilen- und werteweise in Schleifen bearbeitet (also per VBA), weil das logisch und verständlicher erscheint als eine Massendatenverabeitung per SQL.

Man sollte dazu sicher berücksichtigen, dass der Stand an Kenntnissen und Erfahrungen unterschiedlich ist und man eigene "Verhältnisse" nur bedingt auf andere abspiegeln kann. Wer z.B. sich nur an einer DVD-Verwaltung versucht, kann oder will nicht unbedingt ein Verständnis aufbringen
- für (über mehrere Anwendungen hinaus) flexible Objekte, da er vlt. jede Abfrage und jedes Formular genau einmal verwendet,
- für Probleme sehr großer Datenmengen oder einer Mehrnutzerumgebung, da er lokal und alleine die DB nutzt und sein DVD-Regal überschaubar ist.

Um das genannte Wohlgefühl zu bekommen, braucht es meist etwas mehr als ein Zeigen eines Weges, der bei einem Problem einen (den einzigen?) Ausweg bietet, der aber nach Möglichkeit schnell wieder verlassen wird in Richtung "bekanntes Terrain".
Das Mehr sind Schlüsselerlebnisse, die einem verdeutlichen, dass der andere Weg für einen selbst besser, einfacher, ergiebiger ist, und die der Anlass sind, sich offensiv (also über den Ausweg hinaus) damit zu beschäftigen und diesen Weg offensiv (= bevorzugt) anzuwenden.

Mancher wird sich ein solches Schlüsselerlebnis selber schaffen können, indem er selber Beispiele baut und nachvollzieht und daraus Schlussfolgerungen zieht. Viele werden abwarten, bis sie solche Schlüsselerlebnisse mit dem Holzhammer übergezogen bekommen, dann aber auch durchaus vergeblich darauf warten.

 

Hallo!

Ein paar Code-Beispiele, die das gleiche Ergebnis liefern:

1. SQL-String per VBA zusammensetzen
Code:

2. Gespeicherte Parameterabfrage
2a) gespeicherte Abfrage "AbfrageXyz":
Code:

2b) VBA-Code für Recordset:
Code:

3. temporäre Parameterabfrage
Code:

Nun würde es mich interessieren, ob ihr die 1. Variante wirklich übersichtlicher findet?
Wenn ich nur den Ablauf wissen will, kommt mir die Sub Test2 einfacher zum Lesen vor. Will ich auch die SQL-Anweisung schnell im Code erkennen könnten, finde ich die 3. Variante einfacher zum Lesen, da ich dort die SQL-Anweisung ohne dynamische Zusammensetzung zu lesen ist.
Unter "einfach zum Lesen" fällt für mich auch das Entdecken von Fehlern. In Variante 1 muss ich immer relativ genau schauen, ob die Syntax der SQL-Anweisung passt. Bei 2 und 3 stechen mir Fehler um einiges schneller ins Auge, da die Syntax der SQL-Anweisung im Prinzip so vorliegt, als wäre sie bereits zusammengesetzt worden.

Eine Kombination aus zusammengesetzem SQL und Lesbarkeit der SQL-Anweisung wie bei einer Parameterabfrage wäre das Einfügen der Filterwerte in Platzhalter.

4. Platzhalter
Code:

mfg
Josef

 

Da sich noch keiner an die Umfrage traut:

Josef, Deine Hinweise haben ihre Berechtigung, und ich werde einiges davon künftig auch verstärkt nutzen (ich schreibe gerne Gutes ab).

Aber auch: Ich komme ganz gut auch mit Variante 1 zurecht (dieses Replace deckt seltene Sonderfälle ab). Wenn ich ein SQL-Statement per Hand schreibe mit konstanten Werten, muss ich auch Datentypen beherrschen. Da ist der Sprung zur entsprechenden VBA-Entsprechung nicht sehr groß.
Da man gerne und viel Variablen zur Kontrollausgabe per Debug.Print verwenden soll, kann man das auch beim SQL-Statement bei Bedarf ausführen.
Daher: So groß ist der AHA-Effekt nicht, dass ich mit fliegenden Fahnen die Seite wechseln müsste.

Beim Thema Code-Lesbarkeit könnte man auch nachdenken, wie man eine ausführlichere Abfrage wie folgt darstellt: Im Block (möglichst wenige Zeilen), um vom restlichen Code noch etwas zu sehen oder vielleicht mit der SQLInForm-Formatierung:
Code:

 

Hallo!

Da hast du mich eventuell missverstanden.
Ich will dich gar nicht davon abbringen SQL-Anweisungen per Code zusammenzusetzen, wenn du den Umgang mit den unterschiedlichen Datentypen und deren Besonderheiten beherrscht.

Ich möchte nur verstehen, warum so viele diese Variante nutzen, obwohl sie immer wieder Schwierigkeiten haben, die Datenypen in einen SQL-fähigen String zusammenzusetzen.
Meiner Ansicht nach ist es einfacher, eine gespeicherte Abfrage mit Parametern im Abfrageeditor zu erstellen und die Parameterwerte über das QueryDef anzugeben (Variante 2). Bei dieser Variante muss man sich schon bemühen, um einen Fehler einzubauen. *wink.gif*

Das ist bei mir relativ einfach: ausführliche SQL-Anweisungen wirst du in meinem Code selten finden, da ich diese im DBMS als Sicht oder gespeicherte Prozedur unterbringe. *Smilie
Anm.: Vorteil von einem DBMS wie MSSQL: die SQL-Anweisungen sind im Managmeentstudio um ein Vielfaches besser lesbar als in der SQL-Ansicht einer Access-abfrage. Außerdem unterstützt das Managementstudio 2008 IntelliSense - was dazu führt, dass ich ganz wenig Lust verspüre, eine SQL-Anweisung in VBA zu schreiben. *wink.gif*

zu deinem SQL-Beispiel:
Wenn unbedingt alles im VBA-Code stehen soll, könnte man vielleicht auch überlegen, die Unterabfragen in einem extra String abzuspeichern - bzw. überhaupt in einer kleinen Hilfsprozedur den String dieser Unterabfragen aufzubereiten. Dann hätte man nebenbei auch noch die Möglichkeit die einzelnen Unterabfragen zu testen.

Code:

 

Bzgl. Abfragen/Unterabfragen: Dann würde ich besser die Unterabfragen erst gar nicht zu einer einzelnen Abfrage zusammensetzen (eigentlich sind es da 4 Abfragen, die ineinander gesetzt wurden).
Die Frage dazu war aber nur am Rande. Ohne verfügbares oder einsetzbares DBMS wird man aber auf Access und seine Möglichkeiten beschränkt sein, und der Abfrageeditor verfälscht gerne mal etwas aufwändigere gespeicherte Abfragen, und da ist es schon eine Alternative, sich seine Abfrage im VBA-Code sicher zu stellen. Über eine MDE/ACCDE hat man damit zusätzlich die Möglichkeit, die Abfrage dem Zugriff eines Betrachters zu entziehen.

Ich denke, das Kennenlernen von Abfragen erfolgt hier meist mit dem Abfrageeditor, und beim Aufbau eines Kriteriums über Aufbauen (Zauberstab) kann man Formularfelder einbauen, kommt aber nicht zu einer Parameterauflistung. Dass es diese Parameterauflistung auch im Abfrageeditor gibt (über einen Menübefehl), habe ich eben erst durch explizites Suchen festgestellt.
Und zum "Abschreiben" gibt es relativ wenige Beispiele (Du und bspw. Nouba machen da eine Ausnahme), und wie ich oben bereits sagte, etwas sehen und etwas anwenden sind zweierlei.