IBTable.Locate funktioniert nicht bei FB Dialekt 3

[ralfiii]

Hallo!

Ich stelle gerade eine Anwendung um die zum Teil Daten über einen TIBTable einfügt.
Zuerst wird geschaut ob die Daten schon da sind und dann halt entweder ein neuer Eintrag (Insert) angelegt oder der alte aktualisiert (Edit).

Der Code sieht so aus:

Delphi-Quellcode:

with DADataMod.tblPatients do
begin
  Open;
  if Locate('Patient_Id', fPatGuid, [])
  then
      Edit
  else
      insert;
  <Snip>

Seltsamerweise liefert das Locate immer ein False, auch wenn der Eintrag eindeutig schon da ist. Und das nur wenn ich's an einer DB die mit Dialekt 3 erzeugt wurde teste, bei einer alten DB geht's. :wall:

Hilfe!?!?

[hoika]

Hallo,

und wie sieht es mit TIBQuery aus ?
Vielleicht hilft ja ein FetchAll ?


Heiko

[ralfiii]

Zitat:

Zitat von hoika (Beitrag 1087058)

und wie sieht es mit TIBQuery aus ?

Funny!

Also, Mini-Table:

Code:

CREATE TABLE NEW_TABLE (
    INTFIELD      INTEGER,
    STRFIELD      CHAR(5),
    VARCHARFIELD  VARCHAR(5)
);

drin eine Zeile mit den Daten 123 / "123" / "abc"

Die Query "Select * From New_TAble where StrField='123'" liefert den Eintrag.
Lies ich dann allerdings das Feld "StrField" aus, krieg ich
"123_________________" -> "123" und 17 Leerzeichen
Frag ich die Länge via SQL ab ("Select Char_Length(StrField) ...") liefert Firebird den Wert 5. (das kann ich noch verstehen, ist halt kein VarChar)

Und zu allem Überdruss:

Bei folgendem Code funktioniert das Locate am integer- und am VarChar-Field, nicht aber am Char-Field. Kacke!

Delphi-Quellcode:

  IBTable1.Open;
  if IBTable1.Locate('IntField', 123, []) then
     ShowMessage('Int found!');        // OK!
  if IBTable1.Locate('StrField', '123', []) then
     ShowMessage('Str found!');        // not found
  if IBTable1.Locate('VarCharField', 'abc', []) then
     ShowMessage('VarChar found!');    // OK
  IBTable1.Close;

[ralfiii]

Zitat:

Zitat von ralfiii (Beitrag 1087239)

Code:

CREATE TABLE NEW_TABLE (
    STRFIELD      CHAR(5)
);

...lies ich dann allerdings das Feld "StrField" aus, krieg ich
"123_________________" -> "123" und 17 Leerzeichen

Genau betrachtet scheint das das Problem zu sein.
Firebird scheint zu meinen char(5) ist ein 20-Zeichen langer String und padded (wie hier beschreiben) mit Leerzeichen.
Nur: Wie kommt fb auf die blöde Idee das Feld zu verlängern?!?

Versteh das nicht.
Soll ich nun die ganzen Char-Felder in VarChar umbauen?!?

[Lemmy]

Hallo,

habe schon lange nichts mehr mit IBX gemacht, aber Jeff Overcash hat IMHO TIBTable und TIBQuery ausschließlich dafür gemacht, damit BDE-Anwendungen schnell konvertiert werden können, mit der Maßgabe TIBTable und TIBQuery dann durch TIBDataset zu ersetzen. Was passiert bei TIBDataset (anstelle von TIBQuery)?

http://entwickler-forum.de/archive/i...p/t-25472.html

Grüße

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.

[ralfiii]

Zitat:

Zitat von Lemmy (Beitrag 1087276)

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.

[Hansa]

Zitat:

Zitat von ralfiii (Beitrag 1087264)

Soll ich nun die ganzen Char-Felder in VarChar umbauen?!?

Entweder das, oder TRIM beim Abfragen der Datensätze (also im SelectSQL) direkt verwenden, oder eben bei der Verarbeitung im Programm per Delphi,

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

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.

[DrUArn]

Hallo,

habe dieses Problem schon bei Turbodelphi gesehen und irgendwie gelöst.

taucht nun in delphi xe - diesmal für mich unlösbar - wieder auf:

ibtable1.Locate('Name',edit1.text,[loPartialKey]) funktioniert
ibtable1.Locate('Name',edit1.text,[]) funktioniert nicht !!, das heißt, man kann nicht nach genauer Schreibweise suchen!!

Scheint an den tlocateoptions zu liegen!

Wäre nicht schlecht, wenn es dafür eine Lösung gäbe

Grüße

[ralfiii]

Zitat:

Zitat von DrUArn (Beitrag 1090908)

Wäre nicht schlecht, wenn es dafür eine Lösung gäbe

Gibt es.
Weg von IBX oder Interbase statt firebird verwenden.
Geht leider nicht anders.

[Lemmy]

Zitat:

Zitat von ralfiii (Beitrag 1090926)

Gibt es.
Weg von IBX oder Interbase statt firebird verwenden.
Geht leider nicht anders.

AHH!! GEBT MIR EINEN ROTEN STIFT... Muss ein Kreuz im Kalender machen ;-) Bringt es also doch beim einen oder anderen was, wenn man das hin und wieder schreibt...

[ralfiii]

Zitat:

Zitat von Lemmy (Beitrag 1090943)

AHH!! GEBT MIR EINEN ROTEN STIFT... Muss ein Kreuz im Kalender machen ;-) Bringt es also doch beim einen oder anderen was, wenn man das hin und wieder schreibt...

Scheinbar :)
(auch wenn ich's zuerst einfach nicht wahr haben wollte)
Also, sprich mir nach: "...ich hab's ja immer schon gesagt!!!" ;)

[DrUArn]

hi,

vielleicht hilft auch das (hatte eben dieses Problem auch unter Interbase)

wenn das Feld ein char-Feld ist, muss dessen Eigenschaft FixedChar auf false gesetzt werden (dann wird nicht gepadded)
dann
tibdataset.locate('acharfield', edit1.text,[]).locate funktioniert!

Als unerfahrener Datenbank-User scheue ich eine Wechsel - kann mann unter Delphi XE prof. einfach in der IDE auf Firebird zugreifen -
gibts visuelle Komponenten-Packs?

MfG

Uwe