Locate findet nix

[wurzelsepp1]

Moin Experten :)

Nach einigen Jahren mache ich mal wieder etwas mit Delphi und bin gleich auf ein Verständnisproblem gestoßen:

Ich suche mit Table.Locate einen Substring. Die Methode finde den aber prinzipiell nicht, trotzdem er vorhanden ist.

Hier ein Beispiel:

Feld: "IP"
Inhalt: "1.2.3.0/24"

Nun will ich nach dem ersten Feld suchen, das die ersten drei Ziffern der Adresse enthält:

T.Locate('IP', '1.2.3', [lopart..

Ergebnis: false

Ein SQL mit Platzhaltern findet alles Ähnliche, ist aber zu langsam und unpräzise.

Wie macht man das richtig?

Danke & VG :)

[hoika]

Hallo,

Zitat:

Ein SQL mit Platzhaltern findet alles Ähnliche, ist aber zu langsam und unpräzise.

IBQuery benutzen
Starting With benutzen
Index auf das Feld IP setzen

PS:
Was passiert, wenn du mal den vollständigen Feldinhalt suchst,
dann auch ohne das foPartialKey.

[haentschman]

Moin...:P

Zitat:

Ein SQL ... ist aber zu langsam und unpräzise.

...habe ich noch nie gehört. :gruebel:

[mkinzler]

Zitat:

Ein SQL mit Platzhaltern findet alles Ähnliche, ist aber zu langsam und unpräzise.

Ein TQuery auf eine SQL-Datenbank (wie z.B. InterBase) ist eine TQuery in der Form

SQL-Code:

select * from <tabelle>;

In diesem Fall ist SQL eigentlich immer schneller und besser, da das DBMS, welches sich dann um die Abfrage kümmert, dafür optimiert ist.

[hoika]

Hallo,
nicht immer,
das IBTable.Locate macht intern auch eine SQL-Abfrage.

Aber:
Information at your fingertips.

Bei mir geht keine Query-Abfrage ohne Prüfung raus zum Kunden.

[mkinzler]

Ohne im Detail geschaut zu haben, glaube ich eher nicht, das ein locate eine neue Abfrage absendet. Es wird ja "nur" der datensatzzeiger in der lokalen Kopie der Daten verschoben. Bei einer Lookup schon eher (oder nur einen lokalen Filter).

Grundsätzlich werden alle Aktionen, welche eine Verbindung zum DBMS benötigen (Refresh, Insert/Update/Delete, ..) in SQL-Statements umgesetzt und vom DBMS ausgeführt. Diese sind in der Regel allgemeiner, als händisch zum Problem bezogen geschriebene.

[hoika]

Hallo,

Zitat:

Ohne im Detail geschaut zu haben

Habe ich aus der Online-Doku ;)
Aber ich glaube das auch erst, wenn da ein SQL-Monitor mitläuft.

[wurzelsepp1]

IBQuery benutzen
Starting With benutzen
Index auf das Feld IP setzen

PS:
Was passiert, wenn du mal den vollständigen Feldinhalt suchst,
dann auch ohne das foPartialKey.[/QUOTE]

Also das habe ich nu probiert und er findet auch das nicht - trotzdem ein passender Datensatz vorhanen ist.

Das Feld in der Datenbank ist vom Typ char und länger als der Suchstring. Könnte der Fehler in einer unterschiedlichen Stringbehandlung liegen?
Muss ich evtl. nach etwas Anderem (z.B. folgenden Leerzeichen) suchen?

[hoika]

Hallo,
hast du Starting With probiert?

[hoika]

Hallo,

Zitat:

trotzdem ein passender Datensatz vorhanen ist

Wohl eher nicht.
Kann es sein, dass der Datensatz mit Leerzeichen gespeichert wurde?

[wurzelsepp1]

Zitat:

Zitat von hoika (Beitrag 1428198)

Hallo,
hast du Starting With probiert?

Noch nicht .. ich hatte noch auf eine Idee zur Wiederbelebung der Locate-Methose gehofft .. :)

Kann "Starting With" im Index suchen?
Das müsste nämlich sehr schnell gehen, da die Suche etwa sekündlich ausgeführt wird ..

[wurzelsepp1]

Zitat:

Zitat von hoika (Beitrag 1428199)

Hallo,

Zitat:

trotzdem ein passender Datensatz vorhanen ist

Wohl eher nicht.
Kann es sein, dass der Datensatz mit Leerzeichen gespeichert wurde?

Die Datenbank wurde aus einer Textdatei (csv) als bulk insert gefüllt. Ich glaube jetzt nicht, dass die Funktion da extra Leerzeichen eingefügt hat ..

[wurzelsepp1]

Zitat:

Zitat von wurzelsepp1 (Beitrag 1428204)

Zitat:

Zitat von hoika (Beitrag 1428198)

Hallo,
hast du Starting With probiert?

Noch nicht .. ich hatte noch auf eine Idee zur Wiederbelebung der Locate-Methose gehofft .. :)

Kann "Starting With" im Index suchen?
Das müsste nämlich sehr schnell gehen, da die Suche etwa sekündlich ausgeführt wird ..

Nachtrag:

Ich hab im Server-SQL-Tool mit "Starting With" gesucht. Dort wird auch nix gefunden ..

[Delphi.Narium]

Zitat:

Zitat von wurzelsepp1 (Beitrag 1428205)

Ich glaube jetzt nicht, dass die Funktion da extra Leerzeichen eingefügt hat ..

Das sollte keine Glaubensfrage, sondern eine Wissensfrage sein.

Gerade bei CSV und Bulk-Insert kann es passieren, dass Daten mit fester Länge in eine Datenbank eingefügt werden, Sprich: Zeichenfolgen werden mit Leerzeichen bis zur Maximallänge der entsprechenden Spalte aufgefüllt.

Nehmen wir an, die Spalte IP sei vom Typ VarChar(15) für z. B. die IP 111.111.111.111. Wenn nun in dieser Spalte die IP 1.2.3.4 steht, werden 8 Leerzeichen angefügt.

Führe bitte mal (sinngemäß) folgendes SQL aus:

SQL-Code:

select * from tabelle where trim(ip) <> ip

Da sollte, wenn keine Leerzeichen angefügt wurden, eine leere Ergebnismenge rauskomen, wenn nicht, weißt Du, dass beim Bulk-Insert Leerzeichen an die Daten angehängt wurden.

Locate wird von mir oft benutzt, das von Dir beschriebene Problem ist da bisher noch nicht aufgetreten und ich kann es auch nicht nachvollziehen.

Zeig' und doch bitte mal alle SQLs, die Du bisher ausprobiert hast und deren Ergebnisse.

T.Locate('IP', '1.2.3', [lopart.. ist irgendwie gut und schön, aber wie sieht der Quelltext dazu aus. Also z. B. das Selectstatement, das T-wasauchimmerdasgenauist zugewiesen wurde.

Kannst Du uns bitte mal den Quelltext von einem Beispielprogramm zur Verfügung stellen, in dem der Fehler reproduzierbar ist?
Oder mal 'nen kurzen Ausschnitt aus des CSV (soweit möglich oder anonymisierte Beispieldaten), damit wir etwas genauer sehen können, worüber hier gerade geredet wird.

[wurzelsepp1]

Zitat:

Zitat von Delphi.Narium (Beitrag 1428207)

Zitat:

Zitat von wurzelsepp1 (Beitrag 1428205)

Ich glaube jetzt nicht, dass die Funktion da extra Leerzeichen eingefügt hat ..

Das sollte keine Glaubensfrage, sondern eine Wissensfrage sein.

Gerade bei CSV und Bulk-Insert kann es passieren, dass Daten mit fester Länge in eine Datenbank eingefügt werden, Sprich: Zeichenfolgen werden mit Leerzeichen bis zur Maximallänge der entsprechenden Spalte aufgefüllt.

Nehmen wir an, die Spalte IP sei vom Typ VarChar(15) für z. B. die IP 111.111.111.111. Wenn nun in dieser Spalte die IP 1.2.3.4 steht, werden 8 Leerzeichen angefügt.

Führe bitte mal (sinngemäß) folgendes SQL aus:

SQL-Code:

select * from tabelle where trim(ip) <> ip

Da sollte, wenn keine Leerzeichen angefügt wurden, eine leere Ergebnismenge rauskomen, wenn nicht, weißt Du, dass beim Bulk-Insert Leerzeichen an die Daten angehängt wurden.

Locate wird von mir oft benutzt, das von Dir beschriebene Problem ist da bisher noch nicht aufgetreten und ich kann es auch nicht nachvollziehen.

Zeig' und doch bitte mal alle SQLs, die Du bisher ausprobiert hast und deren Ergebnisse.

Also:

select * from "TABLE" where "IP_IDX" starting with '1.0.72'
Liefert: nix

select * from "IP2GEOID"
Liefert: alles

select * from "IP2GEOID" where "IP_IDX" like '%1.0.72%'
Liefert alle Satensätze in denen der Suchstring vorkommt

Frage die bleibt:
Warum funktioniert "starting with" nicht?
und: Wie geht man mit den offenbar angefügten Leerzeichen bei der Teilstringsuche um?

Und: IB scheint die Funktion trim() nicht zu kennen. Da gibt's eine entsprechende Fehlermeldung "Function unknown".

Der Source zu dem Delphi-Test ist tatsächlich so kurz und enthält nichts weiter. Die Suchdaten werden (zu Testzwecken) als Konstante übergeben:

IBTable.Locate('ip_idx', '1.0.72', []);
oder eben
IBTable.Locate('ip_idx', '1.0.72', [loPartialKey]);

Zuvor wird lediglich der Tabellenname und die Datenbankverbindung übergeben.

[hoika]

Hallo,
wenn Select * geht,
dann hole dir doch den ersten Datensatz mal in eine String-Variable und sie dir den Inhalt an.

Und gib uns mal das DDL der Tabelle,
also, wie sie erzeugt worden ist. inclusive der CharSets

[mkinzler]

SQL-Code:

select * from "IP2GEOID" where "IP_IDX" like '%1.0.72%

ist das Aquivalent zu CONTAINING.
STARTING wäre

SQL-Code:

select * from "IP2GEOID" where "IP_IDX" like '1.0.72%

Es scheinen sich wirklich Leerzeichen am Anfang zu befinden.
Kann Interbase immer noch kein TRIM()? Dann benötigst Du eine entsprechende UDF.

[hoika]

Hallo,
er hat ja noch nicht gesagt, welches Interbase.
In UDFs gibt es aber LTrim und RTrim.

Ich schiebe ich es eher auf die Importfunktion.

[mkinzler]

Zitat:

Ich schiebe ich es eher auf die Importfunktion.

Ja, vermute ich ja auch. Ich würde diese eliminieren:

SQL-Code:

update IP2GEOID set ip_ipx = LTRIM(RTRIM(ip_idx));

Zitat:

er hat ja noch nicht gesagt, welches Interbase.

Zitat:

Datenbank: IB • Version: 13.3

Sollte Interbase 2017 sein.

[p80286]

Zitat:

Zitat von wurzelsepp1 (Beitrag 1428208)

Also:

select * from "TABLE" where "IP_IDX" starting with '1.0.72'
Liefert: nix

select * from "IP2GEOID"
Liefert: alles

select * from "IP2GEOID" where "IP_IDX" like '%1.0.72%'
Liefert alle Satensätze in denen der Suchstring vorkommt

Frage die bleibt:
Warum funktioniert "starting with" nicht?
und: Wie geht man mit den offenbar angefügten Leerzeichen bei der Teilstringsuche um?

Zitat:

Warum funktioniert "starting with" nicht?

ist eine nteressante Formulierung. Nur weil das erhaltene Ergebnis nicht das erwartete ist, heißt das ja nicht, daß die Funktion fehlerhaft ist.
Erste Regel bei Datenbankabfragen wenn das Ergebnis nicht meinen Erwartungen entspricht, gibt es die gesuchten Daten überhaupt an diesem Ort?
(Nee ist klar, wenn es sie gäbe, gäb es ja auch das erwartete Ergebnis)
Also wo ist der Unterschied zwischen den gesuchten und den vorhandenen Daten.

Gruß
K-H
Das

SQL-Code:

select * from  "TABLE" where "IP_IDX" starting with '1.0.72'

und

SQL-Code:

select * from  "IP2GEOID" where "IP_IDX" like '%1.0.72%'

vollkommen unterschiedlich sind sollte klar sein, es handelt sich also wohl um einen Flüchtigkeitsfehler.

[Delphi.Narium]

Zitat:

Zitat von wurzelsepp1 (Beitrag 1428208)

Zuvor wird lediglich der Tabellenname und die Datenbankverbindung übergeben.

Das will ich aber auch sehen!

Delphi-Quellcode:

try
  IBTable.Close;
  IBTable.TableName := 'IP2GEOID';
  IBTable.Open;
  if IBTable.Locate('ip_idx', '1.0.72', [loPartialKey]) then begin
    ShowMessage(Format('gefunden wurde: %s',[IBTable.FieldByName('ip_idx').AsString]));
  end else begin
    ShowMessage(Format('nicht gefunden, RecNo = %d, RecordCount = %d, aktuelle IP = %s',
                       [IBTable.RecNo, IBTable.RecordCount, IBTable.FieldByName('ip_idx').AsString]));
  end;
except
  on e : Exception MessageDlg(e.Message,mtError,[mbOk],0);
end;

Geht das? Kommt dabei irgendwas raus? Und wenn ja, was?

Und was liefert

SQL-Code:

select * from IP2GEOID where IP_IDX starting with '1.0.72'

?


Hast Du die IBTable mal mit 'ner TDataSource verbunden und die mit 'nem TDBGrid, um zu sehen, was zur Laufzeit des Programmes da so in der Tabelle enthalten ist? Kann, auch wenn's für das Programm letztlich nicht erforderlich ist, beim Test schonmal recht hilfreich sein.

[hoika]

Hallo,
wir warten wohl erst mal auf weitere Infos.
Ich z.B. warte auf das Ergebnis des Select * -> in String-Variable

Zitat:

Kann "Starting With" im Index suchen?

Ja, kann es, es wird der (Asc) Index benutzt.

[wurzelsepp1]

Zitat:

Zitat von Delphi.Narium (Beitrag 1428245)

Zitat:

Zitat von wurzelsepp1 (Beitrag 1428208)

Zuvor wird lediglich der Tabellenname und die Datenbankverbindung übergeben.

Das will ich aber auch sehen!

Delphi-Quellcode:

try
  IBTable.Close;
  IBTable.TableName := 'IP2GEOID';
  IBTable.Open;
  if IBTable.Locate('ip_idx', '1.0.72', [loPartialKey]) then begin
    ShowMessage(Format('gefunden wurde: %s',[IBTable.FieldByName('ip_idx').AsString]));
  end else begin
    ShowMessage(Format('nicht gefunden, RecNo = %d, RecordCount = %d, aktuelle IP = %s',
                       [IBTable.RecNo, IBTable.RecordCount, IBTable.FieldByName('ip_idx').AsString]));
  end;
except
  on e : Exception MessageDlg(e.Message,mtError,[mbOk],0);
end;

Geht das? Kommt dabei irgendwas raus? Und wenn ja, was?

Und was liefert

SQL-Code:

select * from IP2GEOID where IP_IDX starting with '1.0.72'

?


Hast Du die IBTable mal mit 'ner TDataSource verbunden und die mit 'nem TDBGrid, um zu sehen, was zur Laufzeit des Programmes da so in der Tabelle enthalten ist? Kann, auch wenn's für das Programm letztlich nicht erforderlich ist, beim Test schonmal recht hilfreich sein.

Also, das Codebeispiel liefert natürlich den Nicht-gefunden-Dialog und der Zeigt auf den ersten Datensatz der Tabelle. Sollte der auf den letzten zeigen?

Das SQL-Query in deinem Beispiel liefert nichts. Bei den SQL-Abfragen kriege ich nur Daten wenn ich keine Klausel angebe oder aber einen Platzhalter vorn und hinten, also "like '%1.2.3%'"

Noch ein Nachtrag:
Ich habe die Idee mit dem DBGrid mal eingebaut. Die Tabelle, in der Loacate suchen soll, wird nicht bewegt. Daher auch die Anzeige in den Dialogfeld für Recno. Unklar ist mir, warum Recordcount einen Phantasiewert anzeigt. Wenn ich durch das dbgrid scrolle, nimmt dieser Wert auch mal einen Wert um die 100 an. Die Anzahl der Datensätze liegt aber bei 4 Mio ..

[hoika]

Hallo,
und was ist mit meiner Frage? Wie ist denn nun der genaue Wert des Feldes?

RecordCount ist die Anzahl der intern (lokal) geladenen Datensätze.
Willst Du die Anzahl in der DB, musst du FetchAll in den Optionen setzen.
Dann werden ALLE Datensätze lokal geladen und dabei fleißig gezählt.

[Jasocul]

Zitat:

Zitat von wurzelsepp1 (Beitrag 1428596)

Das SQL-Query in deinem Beispiel liefert nichts. Bei den SQL-Abfragen kriege ich nur Daten wenn ich keine Klausel angebe oder aber einen Platzhalter vorn und hinten, also "like '%1.2.3%'"

Mit anderen Worten, es steht vor und hinter dem Suchbegriff irgendetwas. Vermutlich Leerzeichen.
Ein Locate (mit loPartialKey) arbeitet meines Wissens nur korrekt, wenn der Suchbegriff am Anfang steht. Das ist aber hier ganz offensichtlich nicht der Fall. Daher kann das Locate auch nicht das gewünschte Ergebnis liefern. Die Daten sind schlicht falsch aufgebaut.

[mkinzler]

Zitat:

Mit anderen Worten, es steht vor und hinter dem Suchbegriff irgendetwas. Vermutlich Leerzeichen.

Diese Vermutung haben wir gegenüber ihm ja schon mehrmals geäussert und auch beschrieben, wie er das Problem lösen kann. Er glaubt uns aber anscheinend nicht.

[Jasocul]

Richtig, aber jetzt hat er sogar selbst den Beweise geliefert.
Deswegen habe ich das nochmal so deutlich geschrieben.:wink:

[Delphi.Narium]

Delphi-Quellcode:

var
  i : Integer;
  k : Integer;
  sl : TStringList;
begin
  sl := TStringList.Create;
  for i := 1 to 10 do begin
    for k := 0 to IBTable.FieldCount - 1 do begin
      sl.Add(Format('%s: >>>%s<<<',[IBTable.Fields[k].FieldName, IBTable.Fields[k].AsString]));
    end;
    IBTable.Next;
    If IBTable.EoF then break;
  end;
  sl.SaveToFile('Tabellenausgabe.txt');
  sl.Free;
end;

Ungetestet, nur hingedaddelt.

Bitte mal in irgendeine Routine, auf 'nen ButtonClick oder so reinbauen, ausführen und das Ergebnis in der Textdatei hier posten oder analysieren.

Zwischen dem Inhalt einer Spalte und den >>> bzw. <<< sollten keine Leerzeichen oder sonstigen "kryptischen" Zeichen sein, sondern nur der reine Spalteninhalt. Ist dem nicht so, dann musst Du die Einleseroutine für die Daten überprüfen oder die Daten entsprechend in der Datenbank korrigieren.

Eine IP sollte in der Textdatei in der Form zu finden sein:

Code:

ip_idx: >>>1.2.3.4<<<

Jegliche andere Ausgabe weist auf Fehler in den Daten hin bzw. die Daten liegen in der Tabelle in anderer Form vor als erwartet,

[hoika]

Hallo,

Zitat:

Richtig, aber jetzt hat er sogar selbst den Beweise geliefert.

korrekt

Zitat:

Das SQL-Query in deinem Beispiel liefert nichts. Bei den SQL-Abfragen kriege ich nur Daten wenn ich keine Klausel angebe oder aber einen Platzhalter vorn und hinten, also "like '%1.2.3%'"

Jetzt müsste der TE (Thread-Ersteller) auch mal die vorgeschlagenen Sachen durchführen und die Ergebnisse posten.

[wurzelsepp1]

Zitat:

Zitat von mkinzler (Beitrag 1428613)

Zitat:

Mit anderen Worten, es steht vor und hinter dem Suchbegriff irgendetwas. Vermutlich Leerzeichen.

Diese Vermutung haben wir gegenüber ihm ja schon mehrmals geäussert und auch beschrieben, wie er das Problem lösen kann. Er glaubt uns aber anscheinend nicht.

Moin Jungs,

Nur zur Klarstellung: Ich glaube euch alles und bin auchnsehr dankbar für eure Unterstützung. Da ich seit fastb20 Jahren nix mehr mitbDelphi gemacht habe, bin ich - zugegeben - nicht mehr auf dem neuesten Stand. :)

Also zur Sache:

Ich kann in meinem SQL Tool nach einem Query auf die Gesamtdaten keine Zeichen am Anfang der Daten erkennen. Nur am Ende der Daten sindmvermeintlich Leerzeichen.
Deshalb konnte ich die These, dass da etwas am Anfang steht, nicht nachvollziehen.

Ichnwerde jetzt dem Vorschlag aufgreifen und dienDaten in einenTextdatei ausgeben und das Ergebnis hier nochmal posten.

Gibt es beinDelphinevtl. Andere Stringbehandlungs Probleme, wie in anderen Sprachen üblich, die zun den Problemen führen könnten?
In der Datenbank sind meine Suchfelder vom Typ vachchar und char. Beide liefern aber die selben Suchergebnisse (keine).

Danke euch & einen sonnigen Montag! :)

[hoika]

Hallo,
ein VarChar(5) und ein Char(5) werden unterschiedlich behandelt.

Steht in dem Feld als Wert 'A', wird zurückgegeben:
beim Char(5) 'A____' (_ = Leerzeichen)
beim VarChar(5) ein 'A'

und auch einen sonnigen Montag ;)

[Jasocul]

Zitat:

Zitat von wurzelsepp1 (Beitrag 1428629)

Ich kann in meinem SQL Tool nach einem Query auf die Gesamtdaten keine Zeichen am Anfang der Daten erkennen. Nur am Ende der Daten sind vermeintlich Leerzeichen.
Deshalb konnte ich die These, dass da etwas am Anfang steht, nicht nachvollziehen.

Das ist verständlich. Es gibt aber SQL-Tools, die führende Leerzeichen automatisch beim Visualisieren im Grid ausblenden. Wenn ich mich richtig erinnere, kann das auch eine Einstellung in der Datenbank sein, bzw. gibt es auch DB-Komponenten, die das als Voreinstellung so machen.

Wenn beim Select nur dein Wunsch-Ergebnis erreicht wird, wenn das like vorne ein "%" benötigt, ist das schon eindeutig.

[wurzelsepp1]

Ich habe die Tabellenspalten nu in eine Textdatei ausgeben lassen und bekomme als Ergebnis ebenfalls keine führenden Leer- oder Sonstwiezeichen:

NET_IP: >>>1.0.0.0/24 <<<
GEO_ID: >>>2070667<<<
IP_IDX: >>>1.0.0.0/24 <<<
NET_IP: >>>1.0.1.0/24 <<<
GEO_ID: >>>1811017<<<
IP_IDX: >>>1.0.1.0/24 <<<

Sehr ich die Datei jedoch mit dem Hex-Editor an, kann ich am Anfang der beiden IP-Felder ein LF (!) erkennen.

Das wird wohl die Ursache des Problems sein - und die Erklärung dafür, warum ich das führende Zeichen nicht sehen konnte ..

Ich danke euch für den Tipp mit der Textdatei! :)

Nun zur Lösung: Gibt es eine Funktion bei IB mit der ich das erste Zeichen eines Feldes entfernen kann?

[mkinzler]

Zitat:

Nun zur Lösung: Gibt es eine Funktion bei IB mit der ich das erste Zeichen eines Feldes entfernen kann?

Normlerweise TRIM() oder LTRIM() aus einer UDF-Bibliothek.
Oder SUBSTRING()

[wurzelsepp1]

Sodele: Mit dem Tipp, das erste Zeichen herauszukopieren war das Problem dann gelöst.
Danke an alle, die geduldig geholfen haben! :)

Letzte Anfängerfrage: Kann ich einen Teilstring auch über einen Index suchen?
Wenn ich mit der Option loPartialKey suche, dauert das 5 Sekunden, suche ich ohne die Option, geht das gewünscht schnell, aber findet nicht den Teilstring. Ich habe als Suchstring die ersten drei Felder der IP, in der Datenbank stehen alle vier und das Netzwerk.

Beispiel:
Datenbank -> '1.2.3.4/25'
Suchstring -> '1.2.3'
Findewunsch: Gehe zum ersten Datensatz, der den Teilstring enthält. (in der DB gibt's eh nur einen Datensatz mit dem Suchstring)

Danke :)

[mkinzler]

[CODE = SQL] ... STARTING WITH ...[/CODE] sollte einen vorhandene Index verwenden; CONTAINING aber leider nicht (zumindest bei FireBird)

[hoika]

Tja,
und schon wären wird wieder bei Starting With ...

Also ist das TIBTable doch nicht so clever.
Wobei aus dem Handbuch:

Zitat:

Locate uses the fastest possible method to locate matching records. If the columns to
search are indexed and the index is compatible with the search options you specify,
Locate uses the index.

Du müsst mal mit einem DBMonitor draufsehen, sofern den deine DB-Komponenten unterstützen.
-> Google

Was für ein Index ist denn drauf (ASC, DESC)?
Und ist es nun ein Char oder VarChar-Feld?

[Delphi.Narium]

Wie oft wird gesucht?
Permanent oder sporadisch?
Situationsbedingt?

Eine IBQuery und ein passendes Select können deutlich schneller sein, als ein Locate.

Wenn man 'ne Tabelle nimmt und darin sind 4 Mio. Datensätze und man benötigt davon den letzten Datensatz, wird Locate den finden und man hat gleichzeitig auch alle Datensätze im Speicher (oder der Windowsauslagerungsdatei). Das ist auch bei heutigen System mit viel Speicher und schneller CPU nicht unbedingt die beste Lösung.

Sucht man mit 'ner Query per Select, hat man als Ergebnis in der Regel nur wenige Datensätze, im Idealfall nur einen, als Ergebnismenge.

Weiß man, dass man als Ergebnis nur einen Datensatz bekommt, bzw. will vom Ergebnis immer nur den ersten Datensatz, ist (meiner Meinung nach) eine Query mit einem konkreten Select für diesen Datensatz dem Locate über eine große Datenmenge vorzuziehen.

Bei 'ner parametrisierten Query ist das dann auch im Quelltext kein großer Aufwand.

[wurzelsepp1]

Zitat:

Zitat von hoika (Beitrag 1428666)

Tja,
und schon wären wird wieder bei Starting With ...

Also ist das TIBTable doch nicht so clever.
Wobei aus dem Handbuch:

Zitat:

Locate uses the fastest possible method to locate matching records. If the columns to
search are indexed and the index is compatible with the search options you specify,
Locate uses the index.

Du müsst mal mit einem DBMonitor draufsehen, sofern den deine DB-Komponenten unterstützen.
-> Google

Was für ein Index ist denn drauf (ASC, DESC)?
Und ist es nun ein Char oder VarChar-Feld?

Das Feld in dem ich suche, ist Varchar und der Index ist asc.
Die Datenbankkomponenten sind die von Delphi und dort die IB Komponenten.

[wurzelsepp1]

Zitat:

Zitat von Delphi.Narium (Beitrag 1428667)

Wie oft wird gesucht?
Permanent oder sporadisch?
Situationsbedingt?

Eine IBQuery und ein passendes Select können deutlich schneller sein, als ein Locate.

Wenn man 'ne Tabelle nimmt und darin sind 4 Mio. Datensätze und man benötigt davon den letzten Datensatz, wird Locate den finden und man hat gleichzeitig auch alle Datensätze im Speicher (oder der Windowsauslagerungsdatei). Das ist auch bei heutigen System mit viel Speicher und schneller CPU nicht unbedingt die beste Lösung.

Sucht man mit 'ner Query per Select, hat man als Ergebnis in der Regel nur wenige Datensätze, im Idealfall nur einen, als Ergebnismenge.

Weiß man, dass man als Ergebnis nur einen Datensatz bekommt, bzw. will vom Ergebnis immer nur den ersten Datensatz, ist (meiner Meinung nach) eine Query mit einem konkreten Select für diesen Datensatz dem Locate über eine große Datenmenge vorzuziehen.

Bei 'ner parametrisierten Query ist das dann auch im Quelltext kein großer Aufwand.

Es wird tatsächlich sekündlich gesucht, daher ist die Performance hier ein wichtiger Faktor.

Kann ich auf die Ergebnismenge in IBQuery auch mit Fieldbyname zugreifen?