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

ja danke ... das hatte ja maike schon eingangs beschrieben ... wie gesagt, ich habe eher das Problem, den Code richtig zusammenzusetzten ....

*weiterprobier*

LG Anja

 

Hallo,

ich komme nicht weiter ... bin immernoch dabei, die Ereignisprozeduren zu erstellen: Hab mich erstmal an den Button Volltextsuche gemacht, weil für die Volltextsuche gibts ja nur eine unabhängige Abfrage (basiert nicht mehr auf A1) ... also bleiben die Steps der Prozudur überschaubar:

1) - ok - prüfen, ob im Eingabefeld etwas eingegeben wurde --> nein: MsgBox --> ENDE
2) - ok - SQL String definiert (die Abfrage)
3) - ??? - prüfen, ob die Abfrage Ergbnisse liefert --> nein: MsgBox --> ENDE
4) - ok? - SQL String als Datenquelle für Ausgabeformular definieren
5) - ??? - das "txtDeinTextfeld" befüllen (xx von yy)
6) - ok? - Ausgabeformular öffnen

zu 3) das ist whrscheinlich mein größes Problem: Ich habe keine Idee, wie ich das Ergebnis der SQL-Abfrage auf "leer" oder "enthält DS" prüfen kann. Vermutlich muss ich das Ergebnis in eine temp schreiben, damit dann mit "count" eine Überprüfung gemacht werden kann. Und dafür habe ich keine Idee, wie ich das anstellen soll ...

Code:

Wäre für Unterstützung sehr dankbar.

Füge die DB-Version bei ...

dankeschön

LG Anja

 

So wird die Abfrage noch nicht funktionieren. Kleine Korrekturen sind notwendig: Leerzeichen bei Zeilentrennung, Variablen außerhalb des Strings, Textvariablen eingeschlossen durch Hochkommata.
Code:

Code:

Eine solche Prüfung ist Unsinn, eine Stringvariable kann nicht Null als Wert annehmen, bestenfalls einen Leerstring (""). Dafür, dass die Variable mehr enthält, hast Du aber gerade gesorgt.
Du willst aber sicher wissen, ob die Abfrage Datensätze bringt. Dazu müsstest Du die Datensätze zählen (z.B. DCount), ein Recordset ausführen oder das Formular mit der Abfrage als DH öffnen. In jedem Fall muss die gleiche Abfrage ausführt werden, so dass die dritte Variante am Vernünftigsten erscheint: Ergebnisformular ohne Prüfung öffnen, wenn keine Datensätze vorhanden sind (RecordCount = 0), gleich wieder schließen.
In den beiden anderen Fällen würde man die Abfrage zweimal ausführen müssen (Prüfen + Formular öffnen), und da Du Like als Operator verwenden willst, "riecht" das nach spürbarer Laufzeit und ist somit nicht ganz egal.

 

Moin Anja,
mein Beispiel bekommst du noch als Alternative, habe aber im Moment nicht soviel Zeit, kann also noch ein bisschen dauern.
Zu deinen Fragen:
erstmal ein Hinweis, der SQL-String ist so noch nicht korrekt:
Code:

sucht nach einem Wert in SName der die Buchstabenfolge "strKrit" enthält.
Wenn du nach dem in strKrit enthaltenen Suchbegriff suchen willst, musst du den SQL-String zunächst beenden, mit der Variablen verketten und danach fortsetzen:
Code:

Ich glaube, ich hatte schon mal auf Debug.Print hingewiesen, oder *tongue.gif*
Einen SQL-String kannst du nicht auf Inhalt (Datensätze) überprüfen, das ist ja zunächst mal nur ein Text.
Nach der Zuweisung des Strings als Datenherkunft kannst du prüfen ob das Formular Datensätze enthält und dann entsprechend reagieren. Guck mal in der Hilfe nach Recordset.EOF bzw. Recordset.BOF.
So, jetzt muss ich wieder.
Viel Erfolg, maike

 

ok, danke für die Hinweise mit der Syntax *Smilie

Eine solche Prüfung ist Unsinn, eine Stringvariable kann nicht Null als Wert annehmen

ja weiß ich doch *redface ... das war meine Notiz als Gedankenstüze, was dieser Schritt soll ... das hatte ich ja auch schon kommentiert mit

Ja, ebs: Diesbezüglich hatte ich auch schon eine ähnliche Überlegung: Dieser Schritt muss nicht sein. Das Ausgabeformular wird geöffnet - mit ohne ohne Suchergebnis. Wenn kein Ergebnis gefunden wurde, dann soll das txtdeintextfeld anstatt "x von y" einfach "keine" anzeigen ... Gut das txtdeintextfeld so hinzubiegen, ist vielleicht auch ein kleiner Act.

... das wär auch ok, und einfacher ...
*idee und vermutlich könnte ich damit RecordCount = 0 auch gleich das textfeld entsprechend "hinbiegen" *Smilie DANKE ebs ...

DANKE auch dir, Maike:

UND für

*freufreu* und

ja *Smilie *gleichnochmalraussuch*

Zwei Fragen hab ich noch zu deiner Antwort ebs *redface :

Wie meinst du das?

DH = Datenherkunft? Das muss ich ja sowie so tun, oder?
hab's jedenfalls so eingeplant mit 'Forms!F4c_Suchergebnisse.RecordSource = strSQL für '--> Datenherkunft für Hauptformular und
'Forms!F4c_Suchergebnisse!F4c_UF1_Suchergebnisse.RecordSource = strSQL für '--> Datenherkunft für UFO

ja, aber in dieser Abfrage komme ich nicht drumherum, oder? Einzige Entscheidung, die ich habe: Liefere ich die Platzhalter in der Abfrage selbst - also immer - oder überlasse ich es dem Anwender - also bei Bedarf (momentan ist letzteres der Fall, habe ja auf meinem Such-Formular den Hinweis mit den Wildcards) ...

Und: Ist die Abfrage soweit in Ordnung (performant) oder würdest du da was verändern (bis auf die neue Syntax, die ich noch berichtige)??

Lieben Dank euch, nun bin ich wieder einen Schritt weiter *dance

Guten Abend euch und viele Grüße
Anja

 

Code:

Ja.

Vergleiche Performance in Abfragen von Michael Zimmermann
Code:

Wenn wir von einer erfolgreichen Datenbank ausgehen, also einer mit vielen Datensätzen, ist das Thema Performance ein Thema von Beginn an. Du kannst das aber auch ignorieren. (Viele tun das.)

 

danke ebs für die Antworten, verstanden - du hast mir geholfen *Smilie ...

------ neue Fragen ------

Habe die Eignnisprozedur nun weiter bearbeitet. Und ich habe nun auch bei dem Ausgabeformular die DH im Entwurf entfernt - soll ja per VB-Anweisung gesetzt werden.

Der erste IF-Zweig funzt - wenn ich nichts eingebe, kommt die msgbox ...
der strSQL verlangt dann den Parameterwert SID ... da bin ich noch nicht dahintergekommen, wo da der Fehler liegt.

... weiter - Ich gebe als Parameter irgendwas ein (* oder eine Zahl oder ich schließe das Fester einfach) --> dann öffnet sich das Ausgabeformular *Smilie

Und dann mekert's noch: kann F4c_F4c_Suchergebnisse nicht finden (Fehlercode 2450) - diese Meldung versteckt sich hinter dem geöffneten Formular.

... soweit ich dass sehen kann, prüft's die Sucheingabe nicht, denn wenn ich da was eingebe, was nicht existiert - dann bleibt das txtDeinTextfeld leer und es kommt keine Meldung. Daraus schließe ich; dass die letzte If gar nicht ausgeführt wird ...

Also scheint bei den Zeilen nach dem SQL-String einiges noch nicht zu stimmen (bzw auch im SQL-String selbst nicht) ...

Habt ihr mir nen Tipp?
Code:

dankeschön

LG Anja

 

Für die Fragen müsste ich dann doch mal in die DB hineinsehen. Allerdings kann ich die von mir benötigte Acc2000-DB nicht öffnen ("Access kann Datenbankfenster nicht öffnen"). Da ist wohl etwas schiefgegangen.

Übrigens: Die folgende Zeile ist zu korrigieren - ein entsprechender richtiger Hinweis hat mich erreicht.
Code:

 

Hallo Anja,

Code:

Lass da mal das acDialog raus, das verhindert die weitere Ausführung des Codes bis das Form F4c wieder geschlossen wird.

Bitte gib doch mal den SQL-String per Debug.print aus:
Code:

Warum weist du dem Hauptformular und dem UFO dieselbe Datenherkunft zu? Das verstehe ich nicht. (Deine DB öffnen - gleiches Problem wie schon mal. Und wenn es jetzt auch bei Eberhard nich tut, liegt es wohl nicht an meiner Konfiguration *wink.gif* .)

Der Teil des Codes ab
Code:

gehört in das F4-Formular.
Und es muss wohl so heißen:
Code:

soweit erstmal, damit du weiter kommst.
maike

 

Hallole,

mmh also dass ihr die DB nicht öffnen könnt, versteh ich nicht. ... schade ... ich hänge mal ein paar screens an, damit ihr es "visuell" mitverfolgen könnt.

Danke für die neuen Tipps.

ok, nun bin wieder weiter *Smilie *Smilie

... hänge jetzt an folgendem Punkt (siehe auch Bilder im Anhang):

Code für F3 Suchformular: Der scheint nun sauber zu sein
Code:

Debug.Print: Code:

... dann gehts weiter mit F4c: da meckert der Kompiler und nach dem öffenen werden keine Daten angezeit; Textfeld bleibt leer (was laut Kompiler auch das Prolem darstellt) Code:

Erläuterung zum Ausgabeformular:
DH für HF ist leer; soll ja durch obere Prozedur gemäß des SQL-Strings mit dem jeweiligen Suchbegriff erezugt werden. UFO heißt F4c_UF1_Suchergebnisse (so wie das Steuerlelement des HF - verknüpft von SID nach SID); DH ebenfall keine (das war vorher anders, deshalb kam auch die Parametereingabeaufforderung für SID) Parametereingabeaufforderung kommt nun keine mehr *Smilie

Es dreht sich nun also ums Textfeld bzw diese Zeile:

Me!txtDeinTextfeld = Me.CurrentRecord & " von " & Me.RecordCount

Habt ihr nochmal nen Tipp??

dankeschön LG Anja

 

Code:

Die Kommata musst du dann auch weglassen. Liegt es daran?
Code:

Ich dachte, Dein Ausgabeformular ist ein anderes als das aktuelle ...

Methoden kann man in der Hilfe finden und überprüfen:

Also etwa ...
Code:

Und bezüglich Ausgabeformular: Beachten, dass ein Unterformular vor dem Hauptformular geladen wird. Das kann bei Wertzuweisungen eine Rolle spielen.

 

ja danke, daran lag es

Natürlich - so ist es. Wie kommst du drauf, es sei jetzt anders?

ok, ich habe den Code für F3 geändert - aber da kommt nun wieder der Fehlercode 2450 (siehe neues Bild 6 im Anhang - zeigt F3 mi der Fehlermedlung)
nochmal kurz erklärt ... bei Click auf den Button soll das Ausgabeformular F4c geöffnet werden
(dazu muss ja die DH auch definiert werden - gemäß strSQL)
Was ist da nur falsch, warum findet er das Objekt nicht? Der Formularname stimmt jedenfalls.
Code F3:
Code:

und den Code für F4c (also das HF) hab ich entsprechend geändert
der Debugger springt jetzt allerdings an (Laufzeitfehler 91 - Objektvariable oder With-Blockvariable nicht festgelegt)
und markiert die Zeile als Fehler an:
Code:

Nun bin ich irgendwie ratloser als vorher.

EDIT: Habe Bild 6 geändert (da war ja die Hälfe mit der Fehlermeldung überdeckt und zum besseren Verständnis: Habe noch Bild 7 angehängt ...

Gruß Anja

 

Moin Anja, nicht verzagen, es geht doch weiter *wink.gif*

Weil es nicht geöffnet ist.

Ich verstehe immer noch nicht, wieso du ein Haupt- und ein Unterformular mit der gleichen Datenherkunft versehen willst:
Code:

Klär mich doch bitte mal auf *cool.gif*

Code:

wird angemeckert, weil das Formular kein Recordset hat, wenn du es ohne die Zuweisung der Datenherkunft öffnest.

maike

 

D A N K E *Smilie - ja du hast recht, das tut es *Smilie *Smilie .... habe nur manchmal das Gefühl, dass ich mich manchmal echt doof anstelle. Das krämt mich tatsächlich, weil Relationale Datenbanken für mich nichts Neues sind und ich eigentlich den Durchblick habe und SQL beherrsche ich auch ganz gut. Hätte nicht gedacht, dass VB mir trotzdem so schwerfällt (P.S. Ich muss ehrlich gestehen, dass ich oft auch mit der Hilfe nicht weiterkomme, weil dort zwar die Syntax erklärt wird, aber wie finde ich denn die richtige Anweisung oder den richtigen Befehl für meine Themen ...)

ja *idee muss dann die Defnition der Datensatzherkunft in F4c rein?? Aber wie verweise ich dann von der F4-Klasse in die F3-Klasse, wo ja der SQL-String definiert ist. .... Oder muss ich dass in beiden Klassen bezeichen??

*redface *redface naja, weil ich denke, dass der SQL-String (also quasi die Abfrage A2...) alles liefert, was ich als DH brauche. Bevor du fragst, warum dann HF mit UFO *tongue.gif* - weil ja die Zutaten "Endlos" sind und die Grupierung nach Smoothie nur im Bericht - nicht aber im Formular - geht. Im Formular habe ich die Smoothies (also die Sucheregbnisse) dann zum durchblättern (bin aber für andere Lösungen noch offen. Ich dachte nach den ersten Posts hier, dass das so das Optimum ist - weil das mit dem Bericht sich ja doch nicht so als schick erwiesen hat)

ok - Erklärung: nehmen wir mein Beispiel Bild 2: Wir suchen das, wo 'Suppe' drin vorkommt usw ... siehe Bild2 und 8 -10 im Anhang ... wenn man das in T1_Smoothie nachschaut, stimmt das - es gibt nur die SmoothieID 28, auf die *Suppe* zutrifft ...
Wichtiger Hinweis: (Bild 10 ist so "modifiziert", dass es zeigt, wie es sein soll) - dazu habe ich die DH von der gesamtabfrage A1 genommen und im Bild dann die Datensatzanzahl retuschiert.


LG Anja *die jetzt schnell Feierabend macht und nachhause fährt*

bis nachher

 

Oje. Ich weiß nicht, was du mit deiner Datenbank machst *nene

Hier im Büro hab ich 2003, die Version konnte ich öffnen. Aber nach ein paar Änderungen am Suchformular schmiert mir das Programm ab. Das hatte ich mit dem Zutatenformular damals auch schon ...
Vielleicht solltest du mal alle deine Objekte nach komprimieren und Reparieren in eine neue, leere Datenbank importieren und damit weiterarbeiten.

Habe das Ganze jetzt runterkonvertiert auf 2000 und das Suchformular neu erstellt - nur husch, husch ohne schick *wink.gif* .
Die Volltextsuche ist eingebaut, du müsstest, wenn dir das so zusagt, noch die Datenherkunft des Listenfeldes so umstellen, dass statt der IDs die Klartexte gezeigt werden.
Wenn ich Zeit habe, mach ich heute abend noch mal ein bisschen was an der Stichwortsuche.
maike