Locate findet nix

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