IBTable.Locate funktioniert nicht bei FB Dialekt 3

[Hansa]

Zitat:

Zitat von Lemmy (Beitrag 1087341)

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

Zitat von Hansa (Beitrag 1087355)

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

doch:

Zitat:

Zitat von ralfiii (Beitrag 1087294)

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. :mrgreen: IBX nutze ich ja vorsichtshalber auch nicht, insofern : egal.

[ralfiii]

Zitat:

Zitat von Hansa (Beitrag 1087355)

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

[Hansa]

Diese Sache geht wohl tatsächlich auf das Konto von IBX. Wie hoika gesagt hat, werden neuerdings anscheinend tatsächlich nur soviele Bytes in der DB gespeichert, wie auch da sind. Jetzt egal mit welcher FB-Version das geändert wurde, aber IBX dürfte das nicht mitgekriegt haben. In IBExpert sieht das so aus, wie im Anhang. Da sieht man schön, wie das in einem Client aussieht. Einzige Frage ist da nur noch, ob die DLL (siehe Lemmy) dieses Verhalten verursacht oder die Zugriffskomponenten, in dem Fall also IBX. Ich tippe eher auf IBX, weil da im OI schon die Option TrimCharFields fehlt. Aber wer weiss ? Ich kann nur sagen, dass dieses komische Verhalten weder in IBExpert, noch bei meinen eigenen Programmen bisher aufgefallen ist. Da ist allerdings in allen Fällen FibPlus im Spiel und kein IBX ! Ich würde das mal testen mit Trial.

Wie bei der BDE-Abkündigung : dass die IBX Firebird nicht unterstützen werden ist schon jahrelang bekannt !

[ralfiii]

Zitat:

Zitat von Lemmy (Beitrag 1087276)

P.S.: Ich sags nochmal, bringt zwar nichts, aber dennoch: IBX und Firebird sind nicht wirklich kompatibel bzw. Jeff hat schon 2000 klar gestellt, dass er Firebird mit den IBX nie unterstützen wird.

Das ist mir leider neu.
Ich hab ein wenig getestet und werd auf IBDAC umrüsten. Das scheint ziemlich flott von statten zu gehen.

Die IBDAC-Jungs müssen nur noch ihr Bestellsystem reparieren, 300$ sind nicht 260Euro sondern 216... :-)

Danke für eure Hilfe!

[DelphiBandit]

@ralfiii Gesagt, getan :)

Habe das am Wochenende mit Zeos nach IBDAC auch schon hinter mir. Wenn man mit dem Migration-Wizard von IBDAC nicht weiterkommt, lohnt auch der Blick auf das JVCLConvert, welches der JVCL im Ordner devtools beiliegt. Mit diesem kann man beim projektweiten Ersetzen von Komponenten gerade bei solchen Aktionen viel Zeit sparen. Haben damit seinerzeit auch die BDE in vier Projekten ersatzlos gestrichen.

Trotzdem - vorher Sicherung machen, falls er was kaputt ersetzt :)

[ralfiii]

Zitat:

Zitat von DelphiBandit (Beitrag 1088572)

...JVCLConvert...

:)
IBDAC bringt einen Konvertierungs-Wizard mit der genau das macht.