Locate findet nix

[wurzelsepp1]

Zitat von hoika:

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 von hoika:

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 von wurzelsepp1:

Zitat von hoika:

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 von wurzelsepp1:

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.

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 von Delphi.Narium:

Zitat von wurzelsepp1:

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.

[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]

select * from "IP2GEOID" where "IP_IDX" like '%1.0.72% ist das Aquivalent zu CONTAINING.
STARTING wäre 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:
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 von wurzelsepp1:

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
select * from "TABLE" where "IP_IDX" starting with '1.0.72' und
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.