Office: (Office 2016) Wert aus Textfeld in Abfrage ausgeben

Hallo zusammen,

Ich habe in einem Formular ein Textfeld, in dem ich ein Datum/Stichtag eingebe. Dieses Datum verwende ich als Filterkriterium für diverse Abfragen. Das funktioniert soweit. Was ich nun jedoch leider nicht hinbekomme ist, dass dieser Datums-Wert auch in der Abfrage selbst als zusätzliche Spalte ausgegeben wird. Ich möchte, dass der Nutzer im Abfrageergebnis sieht, auf welchen Stichtag sich dieses bezieht. Einfach im Abfrageentwurf [Forms]![Formularname]![Textfeldname] als zusätzliche Spalte in der Abfrage hinzufügen (so wie ich es als Filterkriterium eintrage) funktioniert leider nicht. Das Abfrageergebnis ist dann in dieser Spalte leer, obwohl das Formular geöffnet und das Textfeld gefüllt sind.

Ich habe auch andere Abfragen, die auf Basis von Werten in Kombifeldern filtern - gleiches Problem, nur dass es dort Text statt eines Datums ist. Abfrage läuft sauber durch, aber ich würde den Wert des Filterkriteriums gern mit ausgeben.

Ich hoffe hier hat jemand von euch eine clevere Lösung (Ggf. auch VBA, da bin ich aber Laie).

Danke vorab und viele Grüße

:)

 

Hallo Pepe,

das Vorhaben ist schon vom Ansatz her nicht zielführend, denn Abfragen werden nicht direkt für die Anzeige von Daten verwendet, sondern dienen als Basis für Formulare, welche dann wiederum für die Anzeige der Daten als auch deren Bearbeitung verwendet werden.

In Formularen dann das Kriterium darzustellen, sollte eigentlich kein Problem sein.

Ulrich

 

Das beantwortet leider meine Frage nicht :-) Ich nutze Formulare als Benutzeroberfläche in einem Frontend für User. Dort können sie eingeben mit welchen Kriterien sie eine Abfrage ausgeben wollen. Das Ergebnis sind teilweise lange Listen, die auch als Excel ausgegeben werden können und sollen. Ein Formular als Ausgabe ist da nicht geeignet. Ich halte meinen Weg daher schon für zielführend. Die Nutzer machen nur Abfragen, keine Eingaben. Darum möchte ich schon meine obige Frage wiederholen :-) Die Kriterien sind variabel und teilweise auch mehrere, die mögliche Ausprägung aber auch vorgegeben und teilweise voneinander abhängig - darum bleibt nur ein Text- oder Kombifeld in einem Formular, wo der Nutzer unter vorgegebenen Auswahlmöglichkeiten definieren kann, was er abfragen möchte. Parametereingaben sind da nicht nutzerfreundlich. Das Datum ist auch nur eins von mehreren Feldern - aber genau das möchte ich. Wenn ich weiß wie das geht und Bedarf nach den weiteren Feldern besteht, dann kriege ich es ja hin.

 

Hallo,
Du musst dem Ausdruck auch einen Feldnamen zuweisen.

Wenn das nicht funktioniert, zeige bitte den SQL String der Abfrage mit dem Original Kriterium.

 

Die Abfragen sind sehr komplex. Aber ich verdeutliche es an einem stark verkürzten Beispiel:

Es gibt eine Basistabelle (TBL_BAS_01_200_STRGENTGF) mit Plänen (TBL_BAS_01_200_EKPLAN) - jeder Plan hat ein "Gültig von" und ein "Gültig bis" Datum (TBL_BAS_01_200_STRGENTGFBEGDT und TBL_BAS_01_200_STRGENTGFENDDT).

Der Nutzer gibt nun in einem Formular (FRM_EVAL_011_EFFDT) ein Datum (FRM_EVAL_011_EFFDT) ein (in der Regel heute) um sich die Liste der zu diesem Datum gültigen Pläne anzeigen oder auch als Excel ausgeben zu lassen.

Das Filtern der Abfrage bekomme ich mit dem unten stehenden Code hin und funktioniert auch. Was ich nun möchte ist, dass im Ergebnis der Abfrage auch steht, mit welchem Datum diese Abfrage durchgeführt wurde. In der Excel-Liste die herauskommt, stehen zwar die richtigen Pläne, aber mit einem anderen Stichtag kann sie auch anders aussehen und es weiß niemand mehr, mit welchem Datum diese Liste so gültig war.

Gebe ich jedoch den Ausdruck [Forms]![FRM_EVAL_011_EFFDT]![FRM_EVAL_011_EFFDT] nicht als Filterkriterium, sondern als Ausdruck für weitere Spalte in der Abfrage ein, so bleibt diese Spalte leer.

SELECT TBL_BAS_01_200_STRGENTGF.TBL_BAS_01_200_EKPLAN, TBL_BAS_01_200_STRGENTGF.TBL_BAS_01_200_STRGENTGFBEGDT, TBL_BAS_01_200_STRGENTGF.TBL_BAS_01_200_STRGENTGFENDDT
FROM TBL_BAS_01_200_STRGENTGF
WHERE ((([Forms]![FRM_EVAL_011_EFFDT]![FRM_EVAL_011_EFFDT]) Between [TBL_BAS_01_200_STRGENTGFBEGDT] And [TBL_BAS_01_200_STRGENTGFENDDT]));

 

Moin,
das aktuelle Datum kannst du so als neues Feld einfügen:
Code:

maike

 

Danke. Ich brauche allerdings tatsächlich das Datum aus diesem Textfeld, da es als Filterkriterium für die Abfrage fungiert. In diesem Textfeld ist zwar standardmäßig das aktuelle Datum vorbelegt, es kann aber auch in die Vergangenheit oder Zukunft geändert werden - bspw. wenn man wissen will "was galt letzten Monat" oder "was gilt morgen"?.

 

Da erschrickt man sich ja fürchterlich.

Das kann aber auch daran liegen, dass Deine Bezeichnungen ellenlang und wenig selektiv sind und alles auf den ersten Blick aussieht wie eine Suppe.

Ich habe die gezeigte Abfrage auf Übersichtlichkeit gekürzt und den gewünschten Teil ergänzt.

Als Aufgabe verbleibt, den Parameter ordentlich aus dem Formular heraus zu übergeben sowie das Abfrageergebnis gemäß Bestimmung einzusetzen.
Code:

 

Hallo ebs17,

es gibt keinen Grund sich zu erschrecken sondern sollte nur darauf hinweisen, dass ich hier keinen zweiseitigen SQL-Code posten möchte :-) Der erste Eindruck mag so sein, täuscht jedoch. Die Systematik der Bezeichnungen (welche tatsächlich sehr selektiv sind) hat sich im Dickicht von ca. 40 Tabellen, 180 verschiedenen Feldern und 110 teilweise aufeinander aufbauenden Abfragen spätestens bei der Fehlersuche sehr bewährt :-)

Deinen Ansatz finde ich interessant und verstehe ihn auch. Ich probiere mich nun allerdings bereits zwei Stunden daran ihn umzusetzen und bin an der Stelle schlicht zu unfähig. Das Problem, welches du mir lässt, ist ja gerade die ordentliche Übergabe des Werts im Textfeld an die Abfrage :-) Ich habe es nun hin und her probiert mit eckigen Klammern, ohne eckige Klammern, Punkte, Ausrufezeichen, forms und formulare und komme nicht weiter. Bei Google findet man leider auch keine entsprechenden Beispiele. Ich finde nicht heraus wie ich festlegen kann, dass parMyDate der Wert aus der TextBox sein soll. Ich produziere leider einen Syntaxfehler nach dem anderen. Ohne Deklaration - also mit Eingabeaufforderung - sieht es genau so aus wie ich es möchte (siehe Anhang). Dafür schon mal großen Dank.

Ich verstehe den Spaß daran eine kleine Rest-Aufgabe zu hinterlassen. Aber falls du die Lösung kennst, wäre ich über einen "Wissenstransfer" sehr dankbar. Die Firma dankt, wenn ich meine Zeit möglichst produktiv nutze - zumal ich bereits zwei Tage herum probiert habe, bevor ich diese Frage hier überhaupt gestellt habe :-)

 

Parameterabfrage per VBA öffnen

Wenn Feldbezeichnungen auf dem ersten Dutzend Zeichen identisch mit Tabellenbezeichnungen sind, ist das für mein Gefühl und meinen Gebrauch wenig selektiv. Im Gegenteil, da ich von links nach rechts lese, sieht alles erst einmal ziemlich gleich aus, und wenn man sich mal das Ergebnis einer Abfrage ansehen möchte, so überblickshalber mit vielen und nicht extra verbreiterten Spalten, sehen die Spaltenüberschriften einfach gleich aus.
Ja, und da in meinen Abfragen auch SELF JOIN's vorkommen bzw. gleiche Tabellen öfters vorkommen können, nützt im Feldnamen der vorangestellte Tabellenname auch nicht sehr viel und ist dann nur Ballast. Da ist ein vorangestellter Tabellenalias deutlich aussagekräftiger.
Das ist aber "nur" eine Stilfrage, da ich Abfragen lese und schreibe und nicht nur zusammenklicke und durchaus mit komplexen Abfragen etwas anfangen kann (wobei lang komplex).

An den Spaß habe ich weniger gedacht. Eine Lösung ist ja ein wenig auch vom Umfeld abhängig, in das die Aufgabe eingebettet ist. Das betrifft vor allem den zweiten Teil meines Hinweises. Über am Fall unbekannte Dinge muss ich mir aber nicht den Kopf zerbrechen.

 

Wie gesagt: das hat sich schon sehr bewährt. Unsere Tabellen bauen systematisch, sprich pyramidenartig aufeinander auf und Felder mit gleichem Namen - z.B. STRENTGF - kommen in mehreren Tabellen vor (in Abfragen sowieso natürlich). In der einen Tabelle definiere ich, welche Ausprägungen für STRENTGF es überhaupt geben darf, in der nächsten wähle ich dann zum neu definierten Plan die dazugehörige Ausprägung von STRENTGF aus - Macht schon zwei Mal das Feld STRENTGF. In der einen Tabelle heißt es dann halt TBL1_STRENTGF und in der zweiten TBL2_STRENTGF - grob vereinfacht.

Das sind also technische Feldnamen um im SQL-Code (nicht in der Nutzer-Ansicht) bei Fehlern viel schneller nachvollziehen zu können, woher ein Feld überhaupt kommt - spätestens in Abfragen, wo ich STRENTGF mal aus der einen und mal aus der anderen Tabelle nehme. Für die User-Ansicht der Abfrageergebnisse nutzen wir die sicher bekannte Funktionalität "Beschriftung", so dass der von diesen langen technischen Namen gar nichts zu sehen bekommt :-) Aaaaaaaaaaaaaber das alles geht ja auch am hier eigentlichen Thema vorbei. :-)

Ich danke dir für den Tipp - ich kam anhand deines ersten Kommentars nun nicht auf die Idee zu VBA zu wechseln - worin ich übrigens richtig schwach auf der Brust bin (so in etwa das Level googeln-kopieren-entscheidene-stellen-ersetzen). Im Moment scheitere ich noch an der Umsetzung, aber ich probiere es morgen weiter. Heute ist nicht mehr genug Zeit dafür. Eventuell muss ich noch mehr dumme Nachfragen stellen :-)

 

Hallo Pepe,

hast du nicht gelesen?

gruss ekkehard

 

... würde mich zusätzlich verrückt machen, kommt in den einschlägigen Foren praktisch nicht vor.

Für Spaltennamen nach außen machen sich Spaltenaliase gut. Da sieht man im Code, was woher kommt und wie wohin geht => durchgehende Lesbarkeit ohne woanders nachschlagen zu müssen. Wer sich einmal in ein Datenmodell größer 15 Tabellen hineindenken muss (also eines, das er gerade nicht auswendig kennt), um wirklich anspruchsvolle Abfragen zu schreiben, wird zu schätzen wissen, dass die Konzentration nicht durch Nebenkriegsschauplätze gestört wird.

 

Eine Stilfrage - und wenn man seine Abfragen hauptsächlich direkt als SQL schreibt sicher hilfreich. Da ich aber nicht in SQL schreibe sondern mir die Abfragen im Entwurf zusammenklicke, macht mich das (bisher) nicht verrückt. Im Gegenteil: ein Mal sauber definiert ziehen sich diese Bezeichnungen ja auch bis zum Abfrageergebnis durch. Aber dass es Aliase überhaupt gibt, ist gut zu wissen und kommt bei der nächsten DB evtl zur Anwendung. Auch dafür nochmal „danke“. Wir „können“ Access auch erst seit ca. zwei Jahren. Für das eine oder andere mag es sicher bessere Wege geben - man lernt halt immer dazu. Diese DB ist nun aber schon zu groß und zu komplex um das nochmal von Grund auf zu ändern. Für meine Frage hier macht das aber glaube ich auch keinen Unterschied :-)

 

Hallo ebs17,

wie gestern schon angekündigt, stelle ich mich einfach zu dumm an. Ich habe mich nun den ganzen Tag an dem Code versucht - ohne Erfolg. Das ist der aktuelle Stand und es passsiert: gar nichts. Nicht mal eine Fehlermeldung. Auch wenn ich versuche den Wert "31.07.2020" hart mitzugeben, passiert nichts. MSO 16.0 Access DAO Library ist aktiviert.

Ich habe verschiedene Varianten ausprobiert und offenbar nicht die richtige erwischt. Mein Problem fängt schon bei dem folgenden Satz bei Don Karl an:
"Falls du kein Recordset willst, sondern z.B. bloß eine Aktionsabfrage mit Parametern ausführen, sieht der Code ähnlich aus, nur folgt nach dem Zuweisen der Parameter kein "Set rs…" usw. sondern ein schlichtes:
qdf.Execute"

Ich habe probiert das "Set rs…" wegzulassen und durch qdf.Execute zu ersetzen - mit leider dem gleichen Ergebnis. Da ich ehrlich gesagt auch nicht weiß, was ein Recordset ist, weiß ich auch nicht, ob ich nun einfach nur eine Abfrage ausführen will oder ob ich diese durch die Mitgabe eines Parameterswerts in die Spalte "Stichtag" verändern will.

Weißt du wo der Fehler liegt?

Danke

Dim db As DAO.Database
Dim rs As DAO.Recordset
Dim qdf As DAO.QueryDef

Set db = CurrentDb
Set qdf = db.QueryDefs("Abfrage2")
qdf.Parameters!parMyDate = Forms!FRM_EVAL_011_EFFDT!FRM_EVAL_011_EFFDT


Set rs = qdf.OpenRecordset(dbOpenDynaset)

qdf.Close: Set qdf = Nothing
rs.Close: Set rs = Nothing
Set db = Nothing