Office: Vom ("globalen") Suchen und Finden...

Servus,
ziemlich müssig, das weiter zu diskutieren.
Die gewünschten Möglichkeiten sind vorhanden und nachgewiesen.
Die Performance dabei ist "gewürdigt". Ebenso der vorgeschlagene Kompromiss.
Alternativ bessere Wege dürfen ja codemässig gerne aufgezeigt werden.
Das rein theoretische "Dagegenhalten" ändert nichts für den Fragesteller.
Ich überlasse gerne das Schlusswort dem ebs17.
und tschüss

 

Eingangs wurde ja eine Vorauswahl per DropDown als Lösung ausgeschlossen. Da müsste man schon wissen, ob die Aufgabenstellung modifizierbar ist, ehe man irgendetwas investiert.
Die vorhandene Codelösung erwartet aber nach dem ersten Schritt auch eine Auswahl der jeweiligen Tabelle, was einer Nachauswahl entspricht und dem ersten Fall nicht unähnlich ist.

Code ansonsten: Gefilterte Auswahlabfragen, bei Mehrfachtreffern per UNION zusammengefasst - was soll man da vorausschauend und ohne jegliche Kenntnis der konkreten DB und der konkreten Anzeigewünsche codieren?
Die nachfolgende Zuweisung einer solchen Abfrage als Datenherkunft (RowSource) an ein Listenfeld ist trivial, die Einstellung der nötigen Spaltenanzahl (ColumnCount) und die Anzeige der Feldnamen (ColumnHeads) ebenfalls.

Das "muss reichen" kann man auch in der Form ausführen, dass man von den bestimmten dreißig Suchen erst einmal fünf umsetzt und die anderen dann folgen lässt, was aber recht rasch gehen würde, wenn man sein System gefunden hat.

 

Hallo Zusammen!

Ich musste erst einmal über das Feedback nachdenken, dass ihr mir gegeben habt und für das ich mich zuerst einmal bedanken möchte. Für meinen konkreten Fall waren das wieder eine Menge wichtiger Denkanstöße.

Und in der Tat bin ich von meinem ursprünglichen Ansatz, eine "Suche für alles/ über alles" umzusetzen, letztendlich abgerückt. Wenn ich es mir recht überlege, scheint mir für meinen Fall eine Lösung sinnvoll zu sein, die eine Abfrage-basierte Sucheingabe in ein Feld mit einer Kategorie-Auswahl via DropDown-Menü und einem Button zum Start der Suche beinhaltet. Ich kann für meinen Anwendungsfall tatsächlich voraussetzen, dass der User weiß, dass er keine Äpfel im Kartoffelkeller finden wird. Insofern ist die von mir zuerst als Einschränkung empfundene Notwendigkeit einer Vorauswahl dann wohl doch eher ein Vorteil (und nicht zuletzt auch in Punkto Implementierung und Erweiterbarkeit wahrscheinlich besser zu beherrschen).

Es wäre toll, wenn ich dafür eine Art Vorlage bekommen könnte. Oder gibt es schon eine für Anfänger verständlich beschriebene und einfach anpassbare "Lösung"? Wenn nicht, und da ich mich nicht wundern würde, wenn ich nicht der einzige wäre, der mangels eigener SQL-Fähigkeiten auf der Suche nach einer guten/funktionierenden Lösung für eine solche Suchfunktion ist, wäre es vielleicht keine schlecht Idee, eine nicht komplett auf meinen Bedarf abgestimmte Lösung zu diskutieren? Natürlich nur dann, wenn überhaupt jemand Lust und Zeit hat, so etwas zur Verfügung zu stellen. Im Grunde könnte man diese doch relativ leicht abstrahieren (denke ich mir so, in meinem jugendlichen Leichtsinn).

Basis der Suche wäre eine Abfrage, die n Felder beinhaltet, welche durchsucht werden sollen. Die Abfrage wäre dann gleichbedeutend mit einer Kategorie für das DropDown-Menü zur Vorauswahl des Suchbereiches. Ein Code-Beispiel, welches zwei Felder und zwei Kategorien beinhaltet, wäre, wenn ich es richtig sehe, dann ohne viel Know-how beliebig erweiterbar. Zwei Felder/ Kategorien deshalb, weil es dann für Anfänger wie mich kaum Syntax-Hürden gäbe.

Falls jemand Lust zu helfen hat, schlage ich also einfach mal vor, dass ich die beiden Abfragen

- "qry_mitarbeiter" mit den Feldern "Name" und "Abteilung" und
- "qry_dienstwagen" mit den Feldern "Typ" und "Kennzeichen" habe.

Die Suche sollte mit Platzhaltern umgehen können und das Feld "Name" würde in meinem Beispiel volle Namen beinhalten, d. h. Leerzeichen müssten möglich sein, damit ich nach "Peter Müller" suchen kann. Wenn die Suche dann noch alternativ zum Klicken auf den "Suchen-Buttons" noch auf die ENTER-Taste reagieren würde, wären meine beispielhaften Spezifikationen eigentlich schon am Ende.

Ach so, die Suche würde ja in ein Formular integriert werden. Die Ausgabe der Ergebnisse sollte dann wohl in Form eines Datenblattes in einem Unterformular erfolgen. Oder gibt es bessere Wege? Ein Endlosformular vielleicht?

Tja und last but not least stellt sich mir eine weitere Frage: Wenn ich den Mitarbeiter via Suche gefunden habe und nicht nur die Abteilung herausfinden wollte, sondern den zugrundeliegenden Datensatz bearbeiten möchte - was mache ich dann? Ist es total illusorisch, in Access ohne gigantischen Aufwand vom Suchergebnis zum existierenden Formular springen zu können (den ausgewählten Datensatz natürlich im Rucksack), um ihn dort zu bearbeiten?

Ich kann nur schlecht einschätzen, ob die obenstehende Anforderungen viel zu hoch gegriffen sind, um hier danach zu fragen. Aber ich frage einfach mal...

Einen schönen Abend allerseits!

L.

 

Du verlangst ziemlich viel, für das bißchen, was du hier anbietest!

Grundsätzlich solltest du dir mehr Einsatz abverlangen.
SQL kann man selbst erlernen. Außerdem ist das Internet ist voll davon.
Siehe auch die Fußleiste von Eberhard >>> SQL ist leicht

Deine beiden Abfragen kannst du selbst erstellen. Dann gehst du auf SQL-Ansicht und schon hast du die erste Hürde genommen.

Name ist ein reserviertes Wort und sollte nicht verwendet werden.

GRUNDLAGEN von Datenbanken
und
GRUNDLAGEN Access sind die beiden Felder die du beackern solltest.

Das ist kein Qualitätskriterium.

Auch das ist nicht unbedingt das Non Plus Ultra der Normalisierung!

Damit man mal einen Einblick bekommt, was den zukünftigen Helfern bevorsteht, solltest du mal ein Beziehungsbild deiner DB zeigen.
Dann kann man klarer sehen.

Gruß
Rainer

 

1. Ich verlange gar nichts. Lesen bildet.
2. Ich biete auch nichts an. Wäre mir entgangen, dass das hier eine Handelsplattform ist.

Bist Du mein Vater? Ich glaube nicht. Also sage mir bitte nicht, was ich tun oder lassen soll. Haben Dir Deine Eltern kein gutes Benehmen beigebracht?

Wenn Du nicht helfen willst, wende Dich doch einfach einem anderen Thema zu. Wäre doch eine Idee, oder?

 

A richtig goschate Rotzpipn der Lightfood.
Da könnts noch was lernen. *grins *grins

 

Servus,
sehr flexibles, weitgehend vorprogrammiertes und frei verfügbares Filterformular von Bitsqueezer.
Bitsqueezers Page
und suche dort nach CCFilterV2_7
Erklärungen zur Anpassung an eigene Bedürfnisse sind in den Klassenmodulen
"clsCCFilter" und "clsCCFilterField" einsehbar.
Die Klassenmodule und deren Codes müssen nicht unbedingt verstanden werden.

 

Eigentlich finden mich die Leute in der Regel viel zu nett. Deshalb habe ich mir wahrscheinlich auch dieses Datenbank-Projekt aufschwätzen lassen, mit dem ich seit zwei Monaten 95% meiner Freizeit verbringe... ehrenamtlich, versteht sich. Dabei musste ich bisher gefühlt 1.000.000 grundlegende Dinge über Access und Datenbanken lernen (und kratze dabei trotzdem nur an der Oberfläche, dessen bin ich mir durchaus bewusst). Für SQL war daher leider bisher sehr wenig Zeit, sorry.

Wenn mir dann jemand auf so eine Art und Weise mit "Einsatz" kommt, ist das halt einfach nur eine dreiste Frechheit und das kann man dann auch mal so sagen, wie es ist.

 

Herzlichen Dank, Ohrkester! Das schaue ich mir sofort mal an...

 

Servus,

Das ist natürlich sehr einfach möglich, wenn die DB die Voraussetzungen einer relationalen Datenbank erfüllt.
Dazu wäre es für alle hier natürlich auch sinnvoll, mal einen Screenshot des Beziehungsfensters zu bekommen.

 

Die Fragen und Zusammenhänge sind gefühlt bereits zu 90 Prozent im Thema beantwortet. Es wäre auch ein Ausdruck von Höflichkeit, gemachte Aussagen im Zweifelsfall ein wiederholtes Mal zu lesen und in sein Bewusstsein und Verständnis zu bringen, statt immer wieder neu zu fragen.
Ich stelle mir an der Stelle die Frage, wieviele meiner Sätze nicht nur kostenlos, sondern umsonst waren (abgesehen vielleicht für Dritte). Ich stelle mir zusätzlich die Frage, ob eine weitere Antwort nicht das gleiche Schicksal teilt.

Die Filterklasse von Bitsqueezer ist eine hervorragende Lösung, bezieht sich aber auf eine (feste?) bestehende Datenherkunft für das Formular und ist etwas sehr anderes als ETWAS ÜBERALL suchen, es sei denn, die Monsterabfrage wird wieder aktuell. Was solls, wenn die Aufgabenstellung in Ausgangssituation und Zielstellung ein Eis in der Julisonne ist (sieht mit jedem Hinschauen anders aus.)
Der Bau eines Kaninchenstalls und der Bau eines elfgeschossigen Hauses sind für manche unterschiedliche Dinge. Mancher Bauherr würde das in seinen Plänen und Taten berücksichtigen.

Beim Zusammenbringen dieser sehr unterschiedlichen Ansätze ist der Hinweis auf "muss nicht unbedingt verstanden werden" wahrlich hilfreich. Ich lese dann gespannt weiteres.
Vielleicht lässt eine Fee ihr Zauberstäbchen fallen.

 

Servus,
@Lightfood: Wer Dich nervt kann von Dir in Deinen persönlichen Daten auf
eine Ignoreliste gesetzt werden.
Das entspannt Dich etwas, weil Du dann nicht mehr dieses OFF-Topic Zeugs
lesen musst, welches Dir ja programmiertechnisch nicht weiterhilft.
Die Bitsqueezer Filterklasse(n) sind genau das Richtige für Dich, da Du Dich ja
nun auf ganz bestimmte Datenherkünfte festlegen willst, welche Du per
Abfragen vorbestimmen kannst.
Das ergibt dann halt x Filterformulare, welche zu erstellen nach dem ersten,
etwas längerem Zeitaufwand dafür, Dir aus den Fingern flutschen wird.

 

Hallo,
@Lightfood ziemlich müssig, das weiter zu diskutieren.
Ziehst dich an ein paar Begriffen hoch, statt der Bitte nach einem Bild deines Beziehungsfensters nachzukommen.

Aus den Beiträgen liest du das heraus, was zu deiner Wunschabfrage passt, ungefragt, ob das Datenmodell dieses überhaupt hergibt.
Und das sollte als erstes geklärt sein.

Meine Zweifel an dem richtigen Datenbanksystem habe ich schon vor etlicher Zeit geäußert.
Access ist ein relationales DBS.
Heißt die Daten stehen in direkter Beziehung zueinander.

Aber, das weißt du sicher.

nach diesem Pensum.

Gruß
Rainer