Hallo.
bisher habe ich als Datenquelle für ein Formular (frmBehaelter) ausschließlich eine Tabelle (tblBehaelter) mit allen Einträgen verwendet.
Jetzt hat es sich ergeben, dass gewissen Datensätze zwar in der Tabelle erhalten bleiben, aber nicht angezeigt werden sollen.
Ich habe das durch Einfügen einer Ja/Nein-Spalte (BehaelterAnzeigen) und der Abfrage (qryBehaelterAnzeigen)
SELECT *
FROM tblBehaelter
WHERE tblBehaelter.BehaelterAnzeigen = True;
realisiert. Keine große Sache
Frage:
Gibt es eine Möglichkeit, anstatt über
Forms!frmBehaelter.RecordSource = "SELECT * FROM tblBehaelter WHERE tblBehaelter.BehaelterAnzeigen = True;"
irgendwie den Abfragenahmen mittels VBA als Quelle für das Formular in der Art
Forms!frmBehaelter.RecordSource = qryBehaelterAnzeigen
zuzuordnen? Das funktioniert in der Entwurfsansichtohne Probleme, aber in VBA in dieser Form eben nicht und die Datensatzquelle soll ja dynamisch - nicht nur über das o.a. Beispiel angepasst werden.
Vielen Dank im Voraus und noch einen schönen Sonntag,
Christian
Hallo,
klar geht das. Es ist einfacher als Du denkst:
Forms!frmBehaelter.RecordSource = "qryBehaelterAnzeigen"
Gruß
Christian
Hallo Christian,
das hatte ich natürlich auch versucht, aber ich bekam immer eine Fehlermeldung, dass die Abfrage nicht gefunden wurde, daher mein Gedanke, dass der Abfragename (qryBehaelterAnzeigen) als Datenquelle interpretiert wurde und nicht die darin enthaltene SQL-Abfrage.
ABER
Da Du definitiv mehr Erfahrung mit ACCESS hast als ich, habe ich mir das Ganze noch einmal zu Gemüte geführt und siehe da, das Problem lag wie immer am DAU (=Dümmster anzunehmender User - also mir)!
Nach dem Ausführen der Abfrage durch Doppelklick im Navigationsbereich stand in der Titelzeile ein anderer Name für die Abfrage als im Navigationsbereich und da viel es mir wie Schuppen von den Augen:
Ich hatte kürzlich zwecks beserer Lesbarkeit im Navigationsbereich eine eigene Kategorie hinzugefügt und neue Verweise einer persönlichen Gruppen-Struktur zugeordnet.
Das alleine wäre ja nicht das Problem gewesen, aber dummerweise habe ich die Abfragen dann dort zwecks besserer Lesbarkeit umbenannt.
Und hier lag der Fehler, denn es wurde nur der Verweis auf den Name der Abfrage geändert, nicht aber der Name der Abfrage selbst. Da ich dann in VBA mit dem geänderten Verweis-Namen gearbeitet habe, konnte ACCESS den richtign Namen der Abfrage natürlich nicht finden!
Schande über mich, aber jetzt funktioniert es genau so, wie es soll ;) .
Vielen Dank,
Christian
Hallo Christian,
ja, das sind manchmal die kleinen Fallstricke in Access. Gibt noch viel mehr davon, wo man auch die Access-Profis erst mal lange grübeln lassen kann. Weil Access auch viele absolut unnötige Eigenschaften hat, die sich dann als Fehlerquelle etablieren, weil man nicht darüber nachdenkt, daß man sie konfiguriert hat.
Besser ist: Möglichst wenig Firlefanz benutzen, dann macht man sich das Leben einfacher. Ein Name sollte nur an einer Stelle definiert werden, in der Objektliste.
Man braucht diese Organisationsstrukturen i.d.R. auch nicht. Dafür gibt es ein Suchfenster (wenn man es denn einblendet) im Navi-Bereich.
Die Möglichkeit, Gruppen zu erstellen und Objekten abweichende Namen zu geben, stammt daher, daß es die Access-Erfinder eine tolle Idee fanden, den Navi-Bereich dem User als Menü zum Aufruf seiner Wunschobjekte zur Verfügung zu stellen. Damit erspart man sich als Entwickler, ein Navi-Formular oder gar die Ribbons programmieren zu müssen. Wie üblich also eigentlich etwas für die Leute, die Access gelegentlich verwenden, die lieber Makros als VBA einsetzen, die Tabellen von Excel 1:1 übernehmen usw.
Weil das die Zielgruppe von Access ist, da es ein Office-Bestandteil sein soll, der auch unerfahrene Verwender in die Lage versetzen soll, schnell eine Anwendung zusammenzuklicken.
Wenn Du ernsthaft Anwendungen schreiben willst, laß es einfach. Weg von Spielereien, hin zu sinnvoller Verwendung, Navi-Bereich sollte der User nie sehen. Und sinnvolle Namensgebung machen Objekte leicht auffindbar.
Gruß
Christian