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:
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.