Hallölöe...

da es in Es-Ku-El ja keine wirkliche Suchfunktion gibt, sondern nur die Möglichkeit mit SELECT * FROM etc. zu filtern, wollt ich mir eine Suchfunktion auf Umwegen selber schreiben.

Ich hab also mein DB-Prog (aus anderen Threads hier ja mittlerweile bekannt ), und verschieden DBEdit-Felder und natürlich ein DBGrid. Und so in etwas soll die Funktion funktionieren: (schematisch)

such-eingabe : String vom Benutzer, wonach gesucht wird
feld-inhalt : der Text des zu durchsuchenden Feldes, entnommen aus dem
zugewiesenem DBEditFeld (mit DBEdit.Text....logisch)

DO
dbquery.next / dbquery.prior
UNTIL
such-eingabe GLEICH feld-inhalt

Jetzt meine Fragen:

• Hat vielleicht schon mal jemand das gleiche versucht, und ist zu dem Ergebniss gekommen, das diese Art der Suche total langsam also uneffektiv ist?
  
• Wie vergleich ich meinen Suchstring mit dem Feld-Inhalt nicht nur auf STRIKTE gleichheit, sondern auf ÄHNLICHKEIT, ich hoffe ihr wisst was ich meine....

mfg und danke für eure bemühungen

kiwicht

Hallo kiwicht,

ich sehe ansich keine Notwendigkeit beim Select eine Suchfunktion zu erfinden. Der WHERE-Befehl ist sehr mächtig und mit den richtigen,
intelligenten Abfragen kommst du sehr schnell zu einen Suchergebnis. Wenn du die Felder in der Datenbank noch indizierst kommt das Ergebnis besonders schnell. Es gibt zwar trigger und stored procedures bei den meisten SQL-Datenbanken aber das heißt mit Kanonen auf Spatzen schiessen. Formulier mal ein Beispiel für deine Suche und ich schreibe dir den SELECT-Befehl.

Gruß

Horst

naja.... mein wunsch hat nicht unbedingt allerhöchste dringlichkeit, und noch weniger ist er wichtig... klar. ich komm ja auch immer zu meinen suchergebnissen und wil mich ja auch nicht wirklich beschweren...

aber manchmal vermisst man doch schon das reine suchen. Mit dem SELECT komm ich ansich ja gut klar, ich willt halt nur wissen ob meine methode performant wäre, und wie ich ein edit-feld mit einem dbedit-feld auf ähnlickeiten überprüfen kann.

mfg
kiwicht

ps: meine datenbank umfasst über 1000 einträge, ich sehe von meinem vorhaben also schon dann ab, wenn du sagst das das nur übelst langsam gehen würde...

Also ich bastel mir immer ein Suchformular, wo man einfach oben was eingibt und im Grid wird sofort das Ergebnis angezeigt. Denn ehrlich gesagt, ist es extrem aufwendig eine Suche zu basteln, die ähnliche Ergebnisse liefern kann wie SQL beim Filtern und 2. ist es ein erheblicher Geschwindigkeitsvorteil und das liegt nicht nur am Fat-Server-Prinzip:

Denn wenn du ALLE deine Datensätze durchsuchen willst (oder eben die, die von der Select-Abfrage kommen) dann musst Du sie erstmal ALLE auf Deinen Client ziehen, stell Dir den Verkehr mal bei 50000 Datensätzen vor! Wenn Du aber eine SELECT-Abfrage mit einer entsprechenden WHERE-Bedingung an den Server schickst, stellt der Dir Deine Datenmenge nach diesem Muster zusammen und schickt sie dir dann. Ergo: Weniger Datenverkeher --> viel schneller.

Soviel zu Deinem Plan zu suchen....

Gruß

Es gibt doch so viele schöne SQL-Befehle :

Select * from tblBlaBlaBla where Wert1 = 10 AND (Wert2 <100 and Wert3 <> 2) order by Wert2

oder

Textvergleiche auf Ähnlichkeit :

Select * from TblBlaBla where Wert1=10 and Wert2 LIKE 'Abc*'

Bei machen Dbs muß mann anstatt * % verwenden

hmmmnnnnjaaaaaa.....

das is ja auch nich das problem.... die sql-befehle kenn ich ja mittlerweile auch von vorne bis hinten. und mein sql-datenbank-such-programm funzt ja einwandfrei, mit allem was dazu gehört... datums-suche, between bla bla bla... damit hab ich als kein problem.

@ugrohne:

das mit der geschwindigkeit ist ja auch warscheinlich das einzigste problem, was ich warscheinlich hätte...

ich glaub ihr wisst nicht wirklich wie ich das meine.

was ist denn ganz definitiv der nachteil von SQL? Das ich, wenn ich einmal den filter gesetzt habe, nur das sehe, was dem filter definitv entspricht! da kann ich mit platzhaltern ja auch nicht viel ausrichten, sei es % oder auch _ ....
Wenn ich aber nur zu dem Datensatz springe, den ich suche, sehe ich auch welche Datensätzte sich in unmittelbarer Nähe befinden. Ich kann also z.B. vergleiche ziehen.... versteht ihr was ich meine?

ich hab zum beispiel eine kundendatei. in dieser datei such ich nach einem kunden, dessen kundencode ich GENAU weiss. per sql, gott sei dank, find ich diesen kunden SOFORT. nun gibt es einen kunden, von dem ich weiss, der heisst ähnlich (!)... wenn ich jetzt aber meinen fillter mit SELECT * wieder entferne, zeigt er mir wieder den allerersten datensatz an, und bleibt nicht bei dem zuletzt gefilterten... das problem ist also, ich muss mich jetzt erst per hand durchwühlen, zu dem zuletzt gefundenen, und kann von dort erst meine recherche weiterführen.

rechne ich jetzt diesen zeitaufwand hoch, gegen den zeitaufwand meiner routine, komm ich um einiges besser weg... versteht ihr mich jetzt???

mfg

Das kannst Du aber auch haben, denn so eine Funktion gibt es auch.

Da fällt mir eigentlich ein, es gibt doch bei den meisten Query-Kompos schon ne Suchfunktion, die Funktion heißt Locate. Da kannste ja Deinen letzten angezeigten Datensatz wieder auffinden, wenn Du eine SELECT-Anweisung machst, die ähnliche Namen mit anzeigt.

Achja und außerdem gibts ne Bookmark-Funktion, hab die zwar selbst noch nie verwendet, aber die soll ab und zu ganz praktisch sein, einfach mal die Hilfe fragen und ausprobieren

Gruß

hmm.. von Locate hab ich im Zusammenhang mit SQL noch nie was gehört... und jetzt mal ausprobiert:



Fehlermeldung:
Invalid TypeCast

? Äh... genau. So stehts aber in der Delphi-Hilfe.... jedenfalls wenn das funzen würde, wärs ja das was ich suche...

mfg

Hallo,

versuche es einmal mit LIKE.



Im Beispiel werde alle Datensätze gefiltert, die mit A beginnen.

kiwicht hat folgendes geschrieben:

markieren Quelltext     1: QueryMeindb.Locate(feld1,'suchbegriff',TLocatOptions(loCaseInsensitive)); Fehlermeldung: Invalid TypeCast

Du brauchst bei locateoptions keine typumwandlung, das ist eine menge, folgendermaßen müsste es gehen:



Gruß