Office: (Office 2003) Rezeptsuche VBA/SQL über Formular mit Eingabefeldern?

Hallo liebe Helfer, Profis und Wissende,

Unter anderem auch dank Eurer Hilfe ist meine Smoothiedatenbank nun soweit, dass ich nun die Rezept-SuFu integrieren möchte. Im Internet und im Forum hab ich leider nichts gefunden, was meiner Vorstellung entspricht (aufgrund der Art und Weise, wie bei mir gesucht werden soll). Das hat mich verwundert und auch ein wenig verunsichert, weil ich meine Vorstellung nicht für so ungewöhnlich halte *eek.gif* …

Nun möchte ich Euch um Rat bzw Hilfe bitten:

Erklärung Datenstruktur:
Ein Rezept ergibt sich aus den Daten von
T1_Smoothies (P SID)
T2_Zutaten (P ZID)
T3_Einheit (P EID)
in der Verknüpfungsrelation TV12_Rezept (P RID) ... ein Smoothie hat also mehrere RID-DS

Meine Rezept-SuFu-Vorstellung (siehe jpg – zeigt das Formular):
ungebundenes Formular (enthält unabhängiges UFO) --> 5 Eingabefeldern und eine Optionsgruppe für Auswahl ODER (1) oder UND (2)
Eingabefeld 1 – 4 und die OG für Rezeptsuche nach Zutaten ; Eingabefeld 5 für Volltextsuche (unter Ausschluss der Zutaten). Die Suchergebnisse sollen in einem Formular dargestellt werden. Wenn kein Ergebnis gefunden wurde, soll eine entsprechende Meldung kommen ... Folglich: Zutatensuche hat verschiedene Fälle - je nach dem wie viele der Eingabefelder befüllt sind und wie die OG eingestellt ist. Dafür werden vermutlich verschiedene SQL-Suchabfragen benötigt? Jedenfalls habe ich schon alle Abfragen (auf der Basis einer Gesamtabfrage, die die Daten aus den Tabellen entsprechend zusammenstellt) erstellt *Smilie.

Meine Schwierigkeiten sind nun folgende:
Das Suchergebnisformular (Endlosdarstellung): Problem ist die Gruppierung nach SID. Analog habe ich einen Bericht (Datenquelle ist momentan die Gesamtabfrage), der die Suchergebnisse nach meinen Vorstellungen darstellt. Jedoch wäre ein Formular als Bildschirmausgabe einfach schöner.

Und dann die 2 Buttons des Suchformulars zu „beleben“: Da ich seither fast keine Erfahrung mit VBA habe, weiß ich nicht, wie ich nun die Abfragen sinnvoll einbinden kann. Vielleicht muss ich das SQL auch gar nicht einbinden, sondern es genügen ein Befehl, der die Abfragen jeweils ausführt und ein Befehl, der dann die Suchergebnisse eben per Formular (bzw ersatzhalber per Bericht) anzeigt? Ich hoffe naütlich, dass die Erstellung der Abfragen schon eine adäquate, sinvolle Vorarbeit ist?
Ich möchte nicht auf meine herkömmliche Methode zurückgreifen: Die Abfragen mittels Makro abrufen (mit Bedingung), um am Ende auf die 2 Buttons anstatt der Ereignisprozedur das Makro zu legen … Denn schließlich soll das meine erste Makrofreie DB werden …

Nun los *Smilie: Ich bin für eure Kritik und euren Rat offen und freue mich auf eure Antworten. Und ich erhoffe mir, dass ich die VBA-Umsetzung mit eurer Hilfe hinbekomme und meine Wünsche/Vorstellungen nicht zu seltsam sind.

P.S. Ich bin kein Neuling, was Access und SQL angeht. Das ist auch nicht meine erste Accessdatenbank. Und Relationale Datenbanken, Datenmodellierung, Normalisierung sind mir durchaus bekannt - ich hoffe, dass ich diese Dinge auch ordnungsgemäß umgesetzt habe. Bevor ihr euch fragt: Nein, ich mache das nicht beruflich, nur privat als mein Hobby *tongue.gif* …. Was VBA angeht, da bin ich Newbi *redface

:)

 

Wenn ich nur das Formular betrachte:

1) Das UFo/Listenfeld Zutatenliste ist überflüssig (siehe 2)).

2) Da nach nicht vorhandenen Zutaten sowieso nicht gesucht werden kann (wegen der festen Tabelle Zutaten), kann man a) auf die unsägliche Wildcardsuche (performancehemmend) verzichten und b) statt der Textfelder Kombifelder verwenden, die die vorhandenen Zutaten anbieten. Das ist schneller in der Eingabe und effektiver in der Verarbeitung (Rückgabe Zutat-ID).

3) Eine Volltextsuche in allen Feldern stimmt mich nachdenklich. Entsprechend Normalisierungsregeln liegen gleiche Werte in einem Feld (ich sag mal: Eine Straße suche ich nicht in Nachnamen, einen Ort nicht beim Geburtsdatum).

4) Somit hätte man in einem solchen "zusammengefassten" Formular genügend Platz, Suchergebnisse direkt anzuzeigen: Die erstellte Abfrage bildet Datenherkunft für diese Anzeige.
Bzgl. erstellte Abfrage: Diese könnte auch nur die gefundenen Smoothies anzeigen und in einem Unterformular weitere benötigte Details. Die gewünschte Zielsituation bestimmt den Weg und somit die zu erstellende(n) Abfrage(n).

Diese Hinweise sind durchgehend VBA-frei.

 

hallo Anja,
nur noch ganz kurz:

Nein, nur eine. Die bekommt dann unterschiedliche WHERE-Teile, je nach Formulareingabe.

Schau dir mal ein Listenfeld an, das wäre meine erste Option für einen schnellen Überblick über die gefundenen Ergebnisse - von da aus ließe sich dann ein Formular mit mehr Einzelheiten oder ein Bericht aufrufen.

Im Prinzip ja. Ich würde die Suchbegriffe (außer die Volltextsuche) über Kombifelder eingeben, die alle als Datenherkunft die Zutatenliste haben. Dann kannst du auch nach der ID suchen statt nach Textstrings.
Die Gesamtabfrage nimmst du als Grundlage und den WHERE setzt du nach Bedarf zusammen. Dazu müssten sich hier im Forum auch Beispiele finden, sonst gucke ich morgen irgendwann noch einmal, wie weit du gekommen bist.
Viel Erfolg, maike

 

Hallo Maike, Hallo ebs *Smilie

Zutatensuche: Ja stimmt. Kombifelder sind effizienter --> habe das UFO entfert und die Zutatenauswahl erfolgt nun per Kombifeld. ... Demnach habe ich auch die Abfragen geändert (where ZID anstatt Zname ...)

Das ist allerdings so ziemlich alles, was ich seither auf die Reihe gebracht habe *weinen ...

Ich wollte dann noch die Abfragen so ändern, dass A1Gesamt überflüssig wird. Dies ist mir nur bei A2_Volltextsuche und A2a_Suche_1Zutat gelungen. Die anderen Abfragen sind diesbezüglich unverändert (nur where ZID anstatt Zname)

Anbei die aktuelle Version (mit Kombifeldern, geänderten Abfragen, Versuch Suchergebnisse Listenfeld im Formular); Anbei auch Übersicht Suchergebnisse und neues Suchformular (jpg) ... sowie auch mal der Bericht ...

Ich verstehe leider auch nicht, wie ihr die Darstellung der Suchergebnisse machen wollt *frown.gif* ...

Wie gesagt, ein Smoothie besteht aus meheren DS in der TV12 (Du kennst das Thema ja bereits, wir hatten ja das mit der UND-Varianten-Abfrage *wink.gif*) ... Deshalb müssen doch die Suchergbnisse auch nach der SID gruppiert werden. Oder anders ausgedrückt: Suchergebnisse sollen wie das F1 Eingabeformular sein, nur untereinander gelistet (siehe Bericht).
Per "zusammengesetztes Formular"? Wie das? Und "extra" wär besser - also nicht im F3 selbst ...
Ansonsten: Das mit der Volltextsuche macht hier schon Sinn: Es werden die Felder SName, SHerkunft, SZubereitung und SHinweise durchsucht nach dem Stichwort oder STRING, Zname wird nicht durchsucht .... Beispiel: Ich will nach dem Stichwort "Suppe" suchen: Es ist nicht gesagt, dass dieses Stichwort nur in einem bestimmten Feld zu finden ist. Es könnte im Namen oder z.B. auch im Hinweis zu finden sein ... Mit Normalisierung hat das eher weniger zu tun und selbstverständlich wird der Smoothiename NICHT im Feld Hinweis eingetragen ...

Ich habe mal ein Formular mit dem Listenfeld erstellt -mmmh ist eher unübersichtlich, oder? ... UND: Problem, da Zubereitung = Memo, kann es in einem Listenfeld nicht verwendet werden ...

Bevor jetzt ein Raunen aufkommt: Ich weiß, dass bei Memo nicht das gesamte Feld bis zum Ende durchsucht wird, dennoch möchte ich auch dieses Feld in meiner Volltextsuche einbeziehen ...



*seufz*

Lieber Gruß
ANja

 

Nicht unbedingt, siehe Acc2003 - SQL (Unter)Abfrage bringt nicht das …
Das Subselect S ermittelt die SID (Smoothie) und könnte somit die Datenherkunft für ein Formular sein. In einem oder mehreren Unterformularen (je nach Bedarf) können dann Details jeweils zum Smoothie dargestellt werden (Verknüpfung über SID wie in der gezeigten Abfrage, geht ja zwischen HFo und UFo analog).

 

Hallo Anja, wollte mir deine DB ansehen, aber ich habe zu Hause nur Access 2000, kannst du sie bitte in diesem Format speichern?
maike

 

Hallo Maike
hallo ebs,

... anbei zwei neue Versionen (einmal 2000, das andere wie gewohnt) ... ich hoffe, die 2000er Version geht ...

ebs:
habe das mit dem UFO ausprobiert. So ohne weiteres gehts wohl nicht? Weil da die smoothies (Hauptformular) nicht als Endlosformular angezeigt werden können, sobald ein Unterformular vorhanden ist. Und die restlichen Felder bekomme ich nicht befüllt. Siehe DB ...

Das mit der SubSelect als Datensatzquelle geht schon, nur habe ich dann in dem Formular nur ein Feld mit der SID (txtSID) = soweit ok. Für alle zugehörigen Felder müßte ich dann den Steuerelementinhalt manuell eintragen?: z.B. Für Smoothiename: = SELECT * FROM T1_Smoothie WHERE SID like [txtSID] ==> und das funzt nicht ==> zeigt #Name? an .... und dann fehlen noch die Zutaten (RID-Datensätze) im UFO

P.S. zum testen des neuen Formulars z.B.: Parameter 1 = 106 und Parameter 2 =107

Das ist irgendwie nicht so ganz das, was eigentlich mein Ziel ist oder ich bin zu doof zu kapieren, was du meinst bzw zu doof ums umzusetzten *eek.gif* Mein Wunsch wäre ein Formular sowie der Bericht aussieht

Grüßle ANja

 

Hm, jetzt werde ich aufgefordert, eine neuere Version von Microsoft IE zu installieren, da sonst das Datenbankfenster nicht geöffnet werden kann?
Den Teufel werd ich tun und meine VM mit sowas versauen *biggrin.gif* .
Ich mache mal ein eigenes kleines Beispiel, aber erst nach dem Tatort - Kiel muss sein *mrcool
maike

 

Dann musst Du Dir ein passendes Access selber bauen. In Formularen gibt es meines Wissens nach nicht gleichwertige Funktionalitäten zum Gruppieren wie in Berichten. Also müssen die Wege anders sein.
Code:

Für Klarnamen musst Du die Abfrage mit der Smoothies-Tabelle verknüpfen.

Das "ohne weiteres" hat auch niemand behauptet.
Was würde an einem Einzelformular stören?

 

naja, dass man dann eben die Suchergebnisse durchklicken muss - aber gut, wenn es anders nicht geht. Ich könnte das nochmal abwägen und mich entscheiden, ob ich dann lieber den Bericht oder das Formular zum durchklicken als Ausgabe möchte ....
Zum Formular: Diese Möglichkeit habe ich nicht so hinbekommen ...
Ich habe für das Hauptformular eine SubSelect als Datensatzquelle genommen, damit wird das textfeld mit dem Feld SID befüllt. Für alle zugehörigen Felder (Smoothiename, Herkunft, Hinweis, Zubereitung) habe ich dann den Steuerelementinhalt manuell eintragen: z.B. Für Smoothiename: = SELECT * FROM T1_Smoothie WHERE SID = [txtSID] ==> und das funzt nicht ==> zeigt #Name? an .... Im UFO (RID-Datensätze) werden die zugehörigen Datensätze auch nicht so angezeigt.
Ich denke, ich versteh schon wie das aussehen soll: Das wäre doch analagog zum Formular Rezepteingabe mit UFO - NUR MIT DEM UNTERSCHIED, dass nur bestimmte Datensätze je nach Suchergebnis angezeigt werden.
Könntest du mal eine Blick in den Formularentwurf F4 und F4_UF1 werfen und schauen, was ich falsch gemacht habe?

Weiterführend noch eine Frage:
Ich weiß leider noch nicht, wie das umzusetzten ist, dass per Ereignisprozedur des jeweiligen Suchbutton (zutaten- o. Volltextsuche im Suchformular (F3)) die entsprechende Abfrage anläuft, und dann das Suchergebnis angezeigt (je nach dem im Bericht B1 oder im Formular F4) wird ... Konkret: weil die Abfragen unterschiedlich sind, nicht nur im where-Zweig?? ...

P.S. Ich gestehe, nachdem ich gestern doch etwas gefrustet war, war mir der Tatort auch lieber *wink.gif* ... schade, dass Schatz lieber was anderes schauen wollte ...

Lieber Gruß
Anja

 

Einem Textfeld kann man keine Abfrage als Steuerelementinhalt zuweisen - auch ein dritter Versuch wird scheitern.
Erweitere die Datenherkunft des HFo, dann kannst Du Textfelder an Abfragefelder binden:
Code:

Die Filterung beschränkt sich auf Subselect S. Daten der UFo´s werden nur über eine geeignete Verknüpfung über SID gefiltert.

 

ok ...

danke ebs ... also die Datensatzherkunft des HF nun festzulegen wäre wenig effektiv, weil die sich ja ändert - je nach eingegebenen Suchkriterien ...

Aber zumindest hab ich nun das Anzeigeformular erstellt, in Anlehung an die Rezepteingabemaske ... so wär es schön, wenn es so funktioniert ... siehe jpg

Müssen jetzt eigentlich die erstellten Abfragen noch umgestellt werden, um die Ereignisprozedur nachher effizient zu machen?? ... "A2_Volltextsuche_ohneA1" und "A2a_Suche_1Zutat_ohneA1" habe ich so umgestellt, dass A1 wegfällt ...



Dankeschön und LG Anja

 

Wo ist da das Problem? Code:

Die SQL-Anweisung wäre die von oben, wobei für S das komplette Subselect eingefügt wird, womit man auch Zugriff auf die Kriterien hat.

 

ja ... naja ...

Problem ist das sogesehen nicht.

Die Datensatzherkunft für das Ausgabeformular ändert sich, je nachdem welche Abfrage auf den Plan gerufen wird ... z.B. wenn 3 Suchkriterien mit OP=2, dann Abfrage "A2c_Suche_3Zutaten_UND" benutzen ... wenn 2 Suchkriterien mit OP=1, dann Abfrage "A2b_Suche_2Zutaten_ODER" benutzen ... usw.

Ich muss also im Code
1) die verschiedenen Fallmöglichkeiten einbeziehen if ...else oder Case ... ...
und dann
2) jeweils die Datensatzherkunft mit Forms!Anzeigeformular.RecordSource = "SELECT ..." zuweisen ...
(((3) und dann noch, dass es auch - je nach Fall und mit der passenden Datensatzherkunft - den Bericht öffnet, wenn man auf den Button klickt))))

... Es gibt somit 3 Ereignisprozeduren: ButtonVolltextsuche und ButtonZutatensuche (F3); ButtonBericht öffnen (F4)

... das ist eher das Problem: den(die) Code(s) zustricken, sodass es funzt ... deshalb hab ich Punkt 3 auch erstmal ausgeklammert. Ich bin froh, wenn ich erstmal die 2 Punkte für die Suchbuttons hinbekomme ...

na denn, bis bald.

Ich versuchs weiter.

Danke und lieber Gruß Anja

 

Hinweis:
- Eine SQL-Anweisung (z.B. für eine Datenherkunft) ist erst einmal ein String (= Text).
- Text kann man zusammensetzen, z.B. aus konstanten Bausteinen und variablen Inhalten.
- So gesehen benötigt man keine verschiedenen Abfragen, aus denen man auswählen muss, sondern man könnte "seine" Abfrage gezielt zusammensetzen.