IBTable.Locate funktioniert nicht bei FB Dialekt 3

[ralfiii]

Zitat von Lemmy:

Was passiert bei TIBDataset (anstelle von TIBQuery)?

Komplett gleiches Verhalten
mit loPartialKey würd's gehen, aber da bleibt das Problem, dass beim Auslesen der viel zu lange String zurückgegeben wird.

In den Feldern sind in der App an der ich arbeite GUIDs drin, immer 32 Zeichen lang.
Das Feld ist als Char(32) definiert, und jetzt spinnt Delphi herum und gibt die Guids mit ewig vielen trailing spaces zurück
Beim Auslesen an zig-hundert Stellen ein Trim() herumzuwickeln ist eine potentielle Fehlerquelle, gefällt mir garnicht.

[Lemmy]

Hi,

habe das eben mal mit den IBDAC nachvollzogen und mit den IBX verglichen (Delphi XE): Die IBX zeigen das Verhalten, die IBDAC nicht, d.h. das liegt nicht an Firebird sondern an den IBX. Wobei wir dann wieder da wären was ich oben schon geschrieben habe: IBX und Firebird passen halt einfach nicht mehr zusammen...

Grüße

[Hansa]

Habe es hier auch mal mit FibPlus getestet. Die IBX haben keine Option die Felder direkt zu trimmen. Bei mir heisst die : poTrimCharFields. Standard ist da true, deshalb fiel mir das Verhalten bisher auch nicht auf. Getestet mit D7. In D2009 finde ich Interbase gerade nicht. Vielleicht gibts ja da was.

[Lemmy]

Mönsch Hansa

Recht hast Du. Ist bei IBDAC auch so... da gibts auch ne entsprechende Option... Allerdings ist mir jetzt noch aufgefallen, dass die CHAR(30) genau 30 Zeichen lang sind, da wird aber keine weiteren Chars angehängt wie oben beschrieben... seltsam... hängt dann vielleicht auch noch an der IBX-Version?

Grüße

[Hansa]

Zitat von Lemmy:

..ist mir jetzt noch aufgefallen, dass die CHAR(30) genau 30 Zeichen lang sind, da wird aber keine weiteren Chars angehängt wie oben beschrieben...

Da wird nichts angehangen. CHAR (30) heisst : 30 Zeichen. VARCHAR (30) heisst : 30 Zeichen. D.h. bei 3 Zeichen und Definition von 30 als Feldlänge werden 27 Leerzeichen aufgefüllt (bei CHAR). Der Unterschied ist eben : CHAR belegt, ob nötig oder nicht die 30 Zeichen. VARCHAR nur soviel wie nötig ist (in dem Fall also nur 3). Letzteres bedeutet einen zusätzlichen Rechenaufwand (hin und her-Rechnerei, wenn sich die Länge ändert...), ersteres einen höheren Speicherplatzbedarf auf der Platte. Ich tendiere mittlerweile etwas mehr zu VARCHAR, denn meistens werden die Felder gar nicht richtig ausgenutzt.

[Lemmy]

Hi Hansa

Zitat von Hansa:

Da wird nichts angehangen. CHAR (30) heisst : 30 Zeichen. VARCHAR (30) heisst : 30 Zeichen.

doch:

Zitat von ralfiii:

In den Feldern sind in der App an der ich arbeite GUIDs drin, immer 32 Zeichen lang.
Das Feld ist als Char(32) definiert, und jetzt spinnt Delphi herum und gibt die Guids mit ewig vielen trailing spaces zurück

[hoika]

Hallo,

Zitat:

Der Unterschied ist eben : CHAR belegt, ob nötig oder nicht die 30 Zeichen

Einspruch Eurer Ehren !

Unter Firebird werden Char und VarChar gleich gespeichert.
Sie werden sogar per RLE noch "gezippt".

Der Unterscheid liegt bei der Übergabe/Darstellung beim Client.

Char(30): 30 Zeichen kommen beim Client an.
VarChar(30): X Zeichen kommen beim Client an (in Abhängigkeit des tatsächlichen Inhaltes).

Vor FB 1.5 wurde beim Char sogar das komplette Char(30) übertrage, danach nur noch die tatsächlichen Bytes.
Das Auffüllen mit Leerzeichen beim Char macht jetzt die fbclient.dll


Heiko

[Hansa]

Ah ja, dann hat sich da ja was geändert. Sie wollten da wohl hauptsächlich die Netzwerk-Belastung reduzieren und die Arbeit an die Clients delegieren. Oder bei CHAR eben nicht. Wie bereits vermutet : das nimmt sich nicht viel. Bei mir gibts nur CHAR, das sind nämlich 3 Zeichen weniger zu schreiben. IBX nutze ich ja vorsichtshalber auch nicht, insofern : egal.

[ralfiii]

Zitat von Hansa:

Da wird nichts angehangen. CHAR (30) heisst : 30 Zeichen.

Wenn das so wäre, dann wäre ich schon aus dem Schneider!
Hinterhältigerweise ist dem eben NICHT so.
Wenn du ein Feld mit Char(10) definierst kriegst du (mit Dialekt 3) dann plötzlich immer 40 Zeichen (Länge*4) zurückgeliefert
Da spinnt IBX leider völlig. Hab das grad unter D2010 und unter D2007 getestet, in beiden Fällen die gleiche Katastrophe.

Und das macht dann in meinem Fall massiv Probleme.

Hiiiilfe!!!

[Lemmy]

HI Ralfii,

wie oben beschrieben hatte ich "nur" das reguläre Verhalten. Könnte jetzt ggf. noch an der Kombination IBX+fbClient.dll Version hängen. Nur zur Sicherheit: Verwendest Du die vom FB-Setup erzeugte gds32.dll (versionsnummer 6.x) oder eine einfach kopierte fbclient.dll (Versionsnummer 2.x)? Im zweiten Fall bitte mal mit der von instClient.exe erzeugten gds32.dll arbeiten.
Ansonsten: Weg von IBX!

cu