Komfortable Suche - Fehler 3078 im VBA Code

[database]

Hallo Franz,

ist eher konzeptlos anstatt in irgendeiner Form nötig

den Hinweis und die von dir zitierten weiteren Nachteile gab es auch schon zu Anfang wobei es ungeachtet dessen
halt für den TO ganz interessant sein kann aus den Code-Zeilen ein paar Lehren zu ziehen, die er in weiterer Folge verwenden kann.

Abgesehen von allen Optimierungsmöglichkeiten liegt der Grund für den neuen Fehler hier begraben:

from [" & TabellenName & "]"

es steht im SQL-String eine Variable, die es nicht gibt.

[Beaker s.a.]

Hallo,

es steht im SQL-String eine Variable, die es nicht gibt

Was uns Gelegenheit gibt mal wieder folgenden essentiellen
Lehrsatz zu zitieren:
Verwende "Option Explicit" in jedem Modul.

[accessy]

Ja, sorry, dass ich die Variable nicht geändert habe.

Also,
der Code läuft nun, aber total unsinnig.
Ich bekomme zwar eine Meldung, dass der Begriff gefunden wurde,
aber nicht WO, bzw. es wird gar nicht zum DS gesprungen.

Dann habe ich mal den Code von Franz genommen.
Der funktioniert auf Anhieb ohne Fehler,
zeigt zwar das Datenfeld an, in dem der Begriff gefunden wurde, aber nicht zugehörigen, gesamten DS.
Und man hat keine Chance der LOOP Schleife zu entkommen, denn die läuft ja so bis EOF.
Eigentlich müsste man die Art der Schleife auf EXIT DO ändern.
Also die MsgBox müsste noch ein "Weitersuchen" und "Cancel" haben.
Dann wäre es wohl perfekt.
Was muss man denn ändern, damit der Code von Franz den DS zeigt?

Vielleicht nochmal etwas zur Sinnigkeit dieser Suche.
Ich habe da mal vor langer Zeit ein kleines EXCEL-Programm geschrieben,
bei dem ich über den Spezialfilter nach Textteilen suche.
Wenn ich einen Begriff eingebe, bei dem ich nicht wußte in welcher Textbox der steht,
ist das über den Spezialfilter eine sehr elegante Lösung.
Einfach InputBox aufrufen, Texteil eingeben und über den gesamten Bereich filtern.
Wird der Textteil gefunden, werden alle DS mit gefundener Lösung in einer Listbox aufgelistet.
Dann nur noch auf die entsprechende Zeile klicken und man hat den DS, den man suchte.

[DF6GL]

Hallo,

ich sag es nochmal: das Ganze ist ein Holzweg...

Wenn ich einen Begriff eingebe, bei dem ich nicht wußte in welcher Textbox der steht,
ist das über den Spezialfilter eine sehr elegante Lösung.

Das mag in Excel sinnvoll sein, in einer DB aber nicht. Dort wird nicht blind in allen möglichen Textfeldern nach einem Text-Vorkommen gesucht, dort wird nach dem Vorkommen eines Textes (oder anderer Werte) in einer Domäne (--> Tabellenfeld/-spalte) gesucht und entspr. der Datensatz mit einem FORMULAR z. B. angezeigt. Wenn eine Suche über mehrere Felder mit gleicher Sinnhaftigkeit erfolgen soll, deutet das auf ein grundlegendes Normalisierungsproblem hin. Solche Suchereien passieren in aller Regel mit einem SQL-Statement (auch Abfrage genannt) etwa nach folgendem Code:



Formular, gebunden an die entspr. Tabelle, in der Daten gesucht (,bzw. aus der Daten gefiltert) werden sollen, und mit Form-Textfeldern, die an die entspr. (und evtl. auch nur erforderlichen) Tabellenfelder gebunden sind.  Für die Ausführen des Codes (der die Filterung vornimmt) , ist die Nutzung einer Ereignisprozedur vorgesehen. In diesen Fällen ist auch ein ungebundenes Textfeld für die Eingabe des Such-Kriteriums anstelle der Inputbox zu empfehlen. Dabei ist , weil die Tabelle(nfelder) und auch Form-Textfelder in aller Regel in einer fertigen DB nicht (mehr) veränderlich sind, keine variable Anzahl von Tabellenfelder vonnöten. Eigentlich weiß man (sollte man zumindest ;-) ), was wo etwas zu finden ist.

Code [Auswählen] Erweitern

Sub btnSuchen_Click()
Me.Filter ="TabellenFeld1 Like '*" & Me!Suchfeld & "*'  or TabellenfeldFeld2 Like '*" & Me!Suchfeld & "*'  or TabellenFeld3   Like '*" & Me!Suchfeld & "*'"
Me.FilterOn =true
End Sub

Hier wird das Filterkriterium wie in einem SQL-String (Abfrage)  syntaktisch als "Where-Condition" , ohne das "Where" , der Filter-Eigenschaft des Forms zugewiesen.  Der Effekt ist, dass das Form dann nur die passenden Datensätze anzeigt, was das eigentliche Ziel des Ganzen ja nun war.



Andere Möglichkeit ist, einen "richtigen" SQL-String an die Eigenschaft "Recordsource" (Datenherkunft) des Formulares zuzuweisen:

Code [Auswählen] Erweitern

Sub btnSuchen_Click()
Me.Recordsource="Select * from tblDeineTabelle Where TabellenFeld1 Like '*" & Me!Suchfeld & "*'  or TabenfeldFeld2 Like '*" & Me!Suchfeld & "*'  or TabellenFeld3   Like '*" & Me!Suchfeld & "*'"
End Sub

Ich empfehle, sich auf www.dbwiki.net mal umzusehen....

[ebs17]

Wenn dann das Dingens zum Laufen gebracht wurde, bestehen da immer noch einige Probleme:

1) Wenn man einen Filter auf ein Feld setzt, werden dann dort erst einmal Null-Werte nicht berücksichtigt, weil man mit Null nicht vergleichen kann. Wenn ich also alle Felder filtere, habe ich eine gute Chance, Datensätze auszufiltern, die ich eigentlich als Treffer sehen wollte.

2) Indexnutzung und damit verbunden mögliche Performance des Filterns spielt anscheinend gar keine Rolle.

MfGA
ebs

[accessy]

Okay Leute,

ich beuge mich der Erfahrung und gebe dieses Vorhaben auf über alle Felder zu suchen.
Ihr habt ganz sicher Recht, dass mein Excel-Spezialfilter hier auf Access keinen Sinn macht.

Aber Annahme, ich reduziere mein Vorhaben auf EIN Datenfeld.
So, wie ihr es sinnigerweise sagt.
Dann wäre das hier aus meiner Sicht echt benutzerfreundlich. Beispiel:

Ich stehe mit dem Cursor im Feld Adresse
Ich klicke auf den CommandButton,
die InputBox will den zu suchenden Begriff haben,
Die Auswahl ist automatisch auf "Teil des Feldinhalts" eingestellt.
Nachdem der zu suchende Begriff in sagen wir mal 22 Datensätzen gefunden wurde,
wird automatisch auf Datenblattansicht geschaltet und tabellarisch angezeigt.
Ende des Suchen Dialogs.

Ich denke, dass der eine, oder andere von euch die Suche
bestimmt schon bedienerfreundlicher umgestaltet hat;
vielleicht sogar exakt so wie in diesem Beispiel.

Wenn ja, dann würde ich den Code gern übernehmen.

[ebs17]

Du fährst Deine Ansprüche zurück, willst aber im Prinzip immer noch excel-like arbeiten. Warum? Was ist das für eine Tabelle, die die Datenherkunft des Formulars darstellt?

Die Frage kann man auch anders formulieren: Willst Du jetzt irgendwie in irgendeiner Tabelle (= Ansammlung von Werten in Zeilen und Spalten) irgendetwas selektieren, oder arbeitest Du in einer geplanten Datenbank (modelliert, normalisiert) und möchtest effektiv und nachhaltig arbeiten?

Die Auswahl ist automatisch auf "Teil des Feldinhalts" eingestellt.

Warum? Ist das eine Eingabeverkürzung, oder sind im Feld keine atomaren Informationen?

MfGA
ebs

[DF6GL]

Hallo,


@accessy:

Ich empfehle, sich auf www.dbwiki.net mal umzusehen....

http://www.dbwiki.net/wiki/Access_Beispieldatenbanken

http://www.dbwiki.net/images/1/19/AccSampleSuchen.zip
http://www.dbwiki.net/images/7/75/AccSampleSearchPopUp.zip
http://www.dbwiki.net/images/e/e0/AccSampleSearchPopUp2.zip
http://www.dbwiki.net/images/6/6f/AccSampleKombiAuswahl.zip
http://www.dbwiki.net/images/9/95/AccSampleKombiAuswahlEndlosform.zip

usw..

[accessy]

Es ist schon nicht ganz einfach aus der EXCEL-Welt mal rauszutreten und in die ACCESS-Welt einzutreten.
Für mich ist ACCESS Neuland.
Ihr habt bestimmt Recht mit all euren Hilfen und kritischen Betrachtungen zu meinen Fragen.

In 95% aller Fälle sucht man einen Teilbegriff. Das behaupte ich jetzt mal so. Und da geht es schon los.
Wie dermaßen benutzerunfreundlich das abgeht.
"Dieser Kunde da, hmmm..... Namen hab ich jetzt nicht drauf.... das war in der ääähhh... irgendeine Allee glaube ich....mal suchen....moment.
So, und nun öffne ich den Formularbasierten Filter.
Ich klicke dann ins Datenbankfeld "Adresse"und gebe erstmal den "*" ein, dann "allee", dann wieder den "*".
So, nun "Filter anwenden"
Der Filter zeigt mir jetzt 75 Treffer an....
Klasse.... Klick..Nein...Klick..Nein....Klick..Nein, auch nicht.....habs gleich...... hmmmm, mal auf Tabellenansicht umschalten und scrollen.
Aaaah, das ist er... gefunden.

Ich weiß, das klingt ein bißchen nach Alzheimer..... aber sagt doch selbst, dass ist benutzerunfreundlich.
In Excel programmierte ich den Filter so, dass die Wildcards automatisch vor und hinter dem Suchbegriff stehen.
Und dann Suche als lookat:=xlPart, statt lookat:=xlWhole.

Daher meine Frage nach einem benutzerfreundlicheren Filter
über die InputBox, Wildcard vorne und hinten, suchen, umschalten auf Tabelle.
Fertig....

[DF6GL]

Hallo,

Code [Auswählen] Erweitern

Daher meine Frage nach einem benutzerfreundlicheren Filter
über die InputBox, Wildcard vorne und hinten, suchen, umschalten auf Tabelle.

Würde eher chaotisch dazu sagen...


Beispiel anbei... (Suchen nach Textfragment im Adressblock)

[Anhang gelöscht durch Administrator]

[Beaker s.a.]

Hallo Achim,
Weiss jetzt gerade nicht welche Access-Version
Du verwendest, aber ab mind. A2010 (2007
weiss ich nicht), ist die gewünschte Funktiona-
lität bereits eingebaut in den Navigationsschalt-
flächen.
Da gibt es jetzt ein Feld "Suchen". Wenn Du
da ein Zeichen eingibst wird sofort zum ersten
DS im Formular gesprungen, der das Zeichen
in irgendeinem Feld enthält. Wenn Du weitere
Zeichen eingibst wird die neue Zeichenfolge ge-
sucht; mit ENTER dann der nächste DS mit dem
Vorkommen des Suchbegriffs. Ausnahme: der
Suchbegriff kommt in einem DS mehr als einmal
vor. Dann wird erst dieser DS durchlaufen bevor
zum nächsten gewechselt wird.
gruss ekkehard

[accessy]

Hallo Franz,

eine bemerkenswerte Sache mit diesem Universalfeld als Filter.
Das ist ja noch besser, als meine Idee mit der Inputbox..etc..etc..

Aber etwas unglücklich ist, dass man nur EINEN Wert, also einen Buchstaben eingeben kann.
Wenn man da ein paar mehr eingeben könnte, das wäre es dann.

[accessy]

Hallo Ekkehard,

ich habe ACCESS aus dem Office XP 2002

[DF6GL]

Hallo,

Extras/Optionen/Tastatur/Zum Ende des Feldes gehen   anhaken...

oder auch:

Private Sub txtSuchen_Change()
Me.Filter = " K_Vorname & K_Nachname & K_Strasse & K_PLZ & K_Ort like '*" & Me!txtSuchen.Text & "*'"
Me.FilterOn = True

Me!txtSuchen.SelStart = 255
End Sub

eine bemerkenswerte Sache mit diesem Universalfeld als Filter.
Das ist ja noch besser, als meine Idee mit der Inputbox..etc..etc..

Du liest offensichtlich die Postings nicht richtig:

In diesen Fällen ist auch ein ungebundenes Textfeld für die Eingabe des Such-Kriteriums anstelle der Inputbox zu empfehlen.

[oma]

Hallo accessy,

nebem den guten Limks von Franz zu entsprechenden Beispielen mal ein einfach gehaltenes Beispiel zum Erläutern des Prinzips. So könntest du nach zahlreichen Feldern "gleichzeitig" filtern u. natürlich auch mit Teilbegriffen. Auch können die Suchfelder im Formularkopf eingebaut sein usw....

Gruß Oma

[Anhang gelöscht durch Administrator]