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

Hallo Maike,

vielen dank für deine Version, ich schaus mir gleich an *Smilie *Smilie *Smilie ....

Ich habe inzwischen festgestellt, dass ich wahrscheinlich nicht richtig konvertiert habe. Liegt es daran?

Oh mein Gott, ich hoffe mit der DB ist alles in Ordnung?? Warum schmiert die bei mir nicht ab? Ich arbeite immer fortlaufend mit der gleicher Version (2000-2003Format), die ich regelmäßig unter neuem Namen speicher ...

Ok, ich habe meine Version nun komprimiert und repariert. Dab hab ich ne neu, leere DB erstellt und dort alle Objekte importiert von der zuvor komprimierten/reparierten Version. Hab davon eine Zip erstellt. Und ich hab diese neu DB konvertiert ins 2000er Formnat. Hab davon ebenfalls eine zip erstellt.

Ich hänge beide Versionen an und hoffe sehr, dass die DB jetzt wieder ok ist *depressed

Sonst weiß ich nicht, was ich tun soll. Muss ich etwa vorne anfangen?

Traurige Grüße

Anja

 

Hallo Maike,

naja, das mit dem Listenfeld find ich nicht so schön ... aber ok, man kann drüber reden. Da wäre nur eine Sache: Wenn ich z.B. 'Igor' eingebe (da gibts zwei DS), dann aktualisiert sich das Listenfeld nicht, sondern es zeigt die Zutaten vom ersten DS an, auch wenn DS 2 von 2 angezeigt wird ...

Ich habe jedoch gesehen, wie du an die Sache ran gegangen bist *Smilie ... die Codes meine ich ... habe in Anlehnung daran versucht, meine Codes zu korrigieren. Leider erfolglos ...

F3:
Code:

F4: Soweit kommt's ja nicht, DebugPrint bleibt leer, kann also nicht mehr dazu berichten *rolleyes.gif*
Code:

... *confused.gif* ... ich weiß einfach nicht weiter und vor der Zutatensuche hab ich inzwischen großen Grauen. Ich bin kurz davor das Ganze einzustampfen *weinen

LG Anja

 

N'Abend Anja,
betrachte das Ganze als Programmierkurs und mach dir nicht solche Sorgen *wink.gif* . Oder hast du da einen Termin im Nacken sitzen?

Das Listfeld hat den Vorteil, dass es im Gegensatz zu einem UFO nicht vor dem Formular geladen wird.
Wenn du auf dem Ufo bestehst, wäre es besser, die Datenherkunft für das Anzeigeform und sein UFO festzulegen und dann nur über das Suchformular einen Filter zu setzen.
Am sinnvollsten finde ich ein Formular, wo oben im Kopf die Suche stattfindet und dann unten in einem Listenfeld oder Unterformular gleich die Ergebnisse angezeigt werden.

Sorry, mein Fehler. Die RowSource für das Listenfeld musst du nicht nur beim Form_Open sondern auch beim Form_Current zuweisen - also den Code dort nochmal wiederholen. Damit aktualisiert es sich dann bei jedem Blättern in den Datensätzen.

War das Formular schon geöffnet?
Sonst nimm mal für testweise das Ufo raus und probiere es ohne aus.

maike

 

Hallo Maike *Smilie *Smilie

du hast Recht, ich sollte nicht so streng mit mir sein. Schließlich ist das mein privates Ding, sozusagen 'Just for Fun' - wenngleich ich es trotzdem mit einer gewissen Ernsthaftigkeit betrachte. Ich sag mal so, wenn die DB bis zum Frühling fertig ist (wenn alle Zutaten dann wieder frisch wachsen *wink.gif*), wär es toll *tongue.gif*

ok überzeugt, ich hab das Formular mit Listenfeld übernommen und angepasst, dass alles so ist, wie es sein soll - ganz allein *happy *happy - siehe Bilder im Anhang. Die Freude an der ganzen Sache hab ich wiedergefunden. Das war genau der Motivationsschub, der mir in letzter Zeit gefehlt hat *Smilie

Das Problem mit dem Laufzeitfehler steht somit nicht mehr im Raum *biggrin.gif*

Ok, 2 Kleinigkeiten gibts noch:
Das Textfeld es heißt jetzt txtvonbis - es zeigt immer 1 von 1 an (ausser es gibt kein Ergebnis) ==> Me!txtvonbis = Me.CurrentRecord & " von " & Me.Recordset.RecordCount ...

und dann dauert es verhältnismäßig lange, bis unten in der Navigationsleiste die Summe der DS angezeigt wird, siehe Bild Suchergebnisse, unten "von 2" - dauert ca. 1,5 - 2 Sek
Ist das für die Volltextsuche normal oder kann man die Codes vereinfachen, sodass die Performance besser wird?

anbei mal die betreffenden Prozeduren:
aus Klassenobjekt Form_F3_Suche:
Code:

aus Klassenobjekt Form_F4_SucheergebListenfeld:
Code:

Code:

Dankeschön Maike, dass du mich vom Listenfeld überzeugt hast und ich dadurch mal wieder ein schönes Erfolgerlebnis hatte *Smilie *Smilie

Schönes WE

LG Anja

 

Das ist kein Code-, sondern ein Abfrage-Performanceproblem. Hier spürst Du die Wirkungen der Volltextsuche (Like *). Bedenken dazu hatte ich bereits weiter oben angemeldet.

Zum Verhalten an sich:

 

Hi,

das sieht doch jetzt richtig gut aus so, klar und übersichtlich *top .

Denk mal drüber nach, was das für einen Grund haben könnte - da kommst du jetzt auch schon ganz von selber drauf *wink.gif* .

Ist das nur die Navigationsanzeige oder braucht das komplette Formular zur Anzeige so lange? Bei den paar wenigen Datensätzen sollte das eigentlich recht flott sein, auch die Suche ohne Index mit den Wildcards.
Wenn es nur die Navileiste ist: die kannst du ja weglassen, die Information wird oben in txtvonbis doch schon angezeigt.
In Form 4 könntest du das Ergebnis von Recordcount gleich zu Anfang in eine Variable schreiben, dann muss nicht mehrfach gezählt werden.
Edit: und dabei den Tipp von Eberhard (.movelast) beherzigen.

Dir auch ein schönes (Rest-)Wochenende,
maike

 

Hallo
Ich wollte euch in eurem Tatendrang nicht bremsen, möchte aber auch darauf hinweisen, das dass IMHO viel Code für nichts ist.
Ob man dabei programmieren lernt möchte ich bezweifeln. Allenfalls verbessert sich der Umgang mit dem Codeeditor.
Nach meiner Erfahrung demoralisiert sowas um so mehr. wenn man sieht, dass es auch einfacher geht.
Welche Suchen möglich seien sollen sollte schon bei db Design berücksichtigt werden.
Und da deins recht ordentlich ist, bieten sich doch recht viele Möglichkeiten an

Was ist zu tun wenn man wirklich eine Volltextsuche braucht?
Eigentlich braucht man ja den vollen Text in einem Feld.
Sonst ist eine Suche über alle Felder!
In der angehängten DB habe ich mal ein Konzept umgesetzt wie ich es bereits seit langem bei DB anwende, die auch damit schnell antworten.
Ergänze die Tabelle Zutaten um ein Markierer
erstelle eine Abfrage die alle Felder in den gesucht werden soll.
Ansonsten db hier runterladen

 

edit: oh hallo kama, hab deine AW erst jetzt gelesen. Naja, ja um die Suche gehts ja nur indirekt. Was das werden soll, ist ja ganz klar definiert und inzwischen auch funktionsfähig gelöst, wie du in den Bildern bei #34 sehen kannst. Damit wär die Volltextsuche fast erledigt und dann fehlt noch die Zutatensuche. Dazu kann ich deine Version einbeziehen, muss mal genauer recherchieren, wie du das gelöst hast *Smilie. INTERESSANTE LÖSUNG, DANKE DIR FÜR DIESES FEEDBACK und DIESE DB KAMA. P.S. Bei der Volltextsuche hängts jetzt noch am verflixten Textfeld - siehe hier weiter unten (das kommt dir sicher bekannt vor *wink.gif*) ...

Also zum Performanceproblem:
eine entscheidene Frage an dich, ebs: mit LIKE und Platzhalter ist nicht die Frage, wenn Volltextsuche, dann gehts nur so, oder wie darf ich dich verstehen??

Anmerkung dazu:
Klar muss man abwägen, was wann wie zum Einsatz kommt, es ist doch immer eine Frage vom Nutzen auf Kosten der Performace. Ich dachte, du meinst diese Überlegung mit deinen Bedenken ... Deshalb habe ich obige Frage nochmal ganz direkt so gestellt (oder würdest du so eine Volltextsuche ohne LIKE und ohne Platzhalter zum laufen bringen??)

ja, ebs hats in seinem Zitat wieder mal genau auf den Punkt gebracht *Smilie:

...

und ja,

... da hab ich auch schon dran gedacht, weil du das im Rezepteingabeformular schon verwendet hast *wink.gif* Code:

... hatte nur seither die genaue Bedeutung davon noch nicht ganz erfasst ....

Werde das einbinden und dann sollte sich das Performanceproblem erledigt haben.


zum Textfeld:
mmh, nein, ich kanns nicht so wirklich erklären. Im Rezepteingabeformular hatte kama das etwas anders gelöst - als das mit dem "Zählen" bei gelöschten DS und DSNEU noch nicht so richtig war ...: Nur jetzt kann nichts gelöscht werden, auch nichts neu gesetzt werden UND vor allem stammen meine Recordsets ja aus dem strSQL und nicht aus einer Tabelle, weshalb ich nicht mit DCount() arbeiten kann, oder?? ... mmh *kopfkratz*

Prozedur aus Form_F1_Rezepteingabe:
Code:

... nen kleiner Tipp noch fürs Textfeld *wink.gif* *bettelblick*????

*Smilie ich danke euch für euere Kommentare und Anregungen *Smilie

LG Anja

 

\@kama:
Darf ich das so verstehen, dass du zunächst alle in Frage kommenden Felder in einem String zusammenfasst und dann die Suche auf dieses eine Feld loslässt? Für die gefundenen DS in der Tabelle einen Markierer setzen und dann das Ganze im Form zur Anzeige bringen? Ich sehe es mir nachher mal an, wenn die DB im A2k-Format ist - so auf den ersten Blick will sich mir der Vorteil nicht erschließen.
maike

 

Primär würde ich versuchen, auf eine Volltextsuche zu verzichten und damit das Problem großräumig zu umgehen. Nach etwas überall zu suchen ist zumindest diskutabel in einer wohlgeformten Datenbank.

Eine Alternative könnte es sein, eine zusätzliche Stichworttabelle einzuführen und somit nach festen Begriffen (bzw. Schlüsseln) suchen zu lassen, womit dann in der Abfrage ein Like verzichtbar wird und man auf Gleichheit prüfen kann. Das ist dann aber etwas mehr Aufwand und besser erst ein Thema, wenn vorhandene Probleme gelöst sind.

 

\@Anja:
Die Anzeige des Textfeldes muss beim Form_Current ebenfalls aktualisiert werden.
Zähl das Recordset einmal durch (.Movelast, .RecordCount, .Movefirst), schreib das Ergebnis in ein Textfeld "von" und danach musst du nur noch den CurrentRecord neu ermitteln.
maike

 

ebs:

... schreib mal nich soviel zwischen den Zeilen *wink.gif* ... ok, Volltextsuche umgehen - nein, des mag i net *tongue.gif*. Mein Anwender soll nicht nur nach Zutaten suchen können, sondern auch Smoothies nach einem Begriff oder String suchen können. Und dann ist es doch hoffentlich schon so, dass meine Datenstruktur "wohlgeformt" ist . Ich habe eine relationale, normalisierte Tabellenstruktur. Meine Volltextsuche bezieht sich zudem nur auf die Tabelle Smoothies, dort jedoch auf mehrere Feldnamen (wie solls denn auch anders sein bei ner Volltextsuche) ...
Für mich passt das dann schon so ...
Das kann man nicht mit Kundename-Straße-Ort vergleichen. Da würde der Straßenname natürlich nur im Feld (bzw Spalte) Straße gesuchen werden. Das liegt daran, dass die Straße NUR im Feld Straße steht, und nicht etwa im Feld Kundename. Mein Realschema ist aber nicht so statisch. Ich gab doch mal das Beispiel "Suppe" in #4. Dieser Begriff bezieht sich nunmal nicht explizit auf ein einziges Feld. Der könnte im Feld Herkunft UND/ODER im Feld Smoothiename vorkommen, u.U. wird er auch im Feld Zubereitung verwendet. Das ist hier auch stark davon abhängig, was sich der Anwender bei der Datenerfassung denkt. Im Beispiel Straße käme er natürlich nicht auf die Idee, diese ins Feld Kundenname einzutragen.


wieder zurück zum letzten Problem *Smilie
Danke euch beiden für die Tipps. Habe das Problem mit der Performance und dem Textfeld gelöst. *Smilie *Smilie
Änderung in der Open-Prozedur:
Code:

und Änderungin der Current-Prozedur:
Code:

Jetzt gehts weiter mit der Zutatensuche ... werde nun mal kamas Version genauer studieren, und bin auch auf seine AW zu Maikes Fragen gespannt.

LG Anja

 

Hallo Anja,
das erste .MoveFirst kannst du wieder rausnehmen. Mit Movelast zum letzten, damit alle da sind und gezählt werden können und dann wieder mit Movefirst zum ersten, das reicht.
die db von kama sehe ich mir jetzt mal an, bin auch schon gespannt.
maike

 

also das performateste ist:
Code:

.. blöd, dass er halt beim letzten stehen bleibt

jede Abweichung ist gleich nicht mehr so performant, wie sich eben unten in der Navi-Leiste zeigt .... z.B. so:
Code:

oder --> so hab ich es jetzt drin

Code:

Kamas Lösung ist echt interessant *Smilie das ist "alles auf einmal" *Smilie
*top kama ... nur da kann ich nicht nach Rezepten mit Apfel UND Mango suchen, oder hab ich da was übersehen?


Halt TEXTFELD tut doch noch nicht ganz *wink.gif*:
Wenn es nur 1 DS gibt, zeigs 0 von 0

Falscher Arlam, jetzt tuts doch - habe den Else-Zweig rausgenommen und das Me!txtvonbis = SmoothieNr & " von " & SmoothieAnzahl unter die Variablendefinitionen genommen ...

LG Anja

 

So, jetzt hat es funktioniert mit kamas db im 2000er Format.
Suche in einem zusammengesetzten Feld finde ich eine gute Idee, wenn es einen Performancegewinn bringt.
Wo ich grundsätzlich anders herangehe: gespeicherte Abfragen mit Formularbezügen. Mach' ich einfach nicht.
Mir ist es lieber, ich habe alles im Code, auch wenn es dann ein paar Zeilen mehr sein mögen.
Was ich richtig gut finde, ist die Zutatensuche über den Markierer. Viel besser als die Kombifeldsuche und kann auch in die bisherige Suchvariante eingebaut werden.
Ich würde noch ein Anzeigelistenfeld mit den ausgewählten Zutaten einbauen, da die Zutatenliste wohl länger werden kann und man so nicht alle im Blick hat.
maike