Delphi-PRAXiS
Seite 1 von 3  1 23      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Delphi IBTable.Locate funktioniert nicht bei FB Dialekt 3 (https://www.delphipraxis.net/158964-ibtable-locate-funktioniert-nicht-bei-fb-dialekt-3-a.html)

ralfiii 9. Mär 2011 15:59

Datenbank: Firebird • Version: 2.1 • Zugriff über: IBX

IBTable.Locate funktioniert nicht bei FB Dialekt 3
 
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 9. Mär 2011 16:51

AW: IBTable.Locate funktioniert nicht bei FB Dialekt 3
 
Hallo,

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


Heiko

ralfiii 10. Mär 2011 11:05

AW: IBTable.Locate funktioniert nicht bei FB Dialekt 3
 
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 10. Mär 2011 11:39

AW: IBTable.Locate funktioniert nicht bei FB Dialekt 3
 
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 10. Mär 2011 11:48

AW: IBTable.Locate funktioniert nicht bei FB Dialekt 3
 
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 10. Mär 2011 12:38

AW: IBTable.Locate funktioniert nicht bei FB Dialekt 3
 
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 10. Mär 2011 13:46

AW: IBTable.Locate funktioniert nicht bei FB Dialekt 3
 
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 10. Mär 2011 13:47

AW: IBTable.Locate funktioniert nicht bei FB Dialekt 3
 
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 10. Mär 2011 14:05

AW: IBTable.Locate funktioniert nicht bei FB Dialekt 3
 
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 10. Mär 2011 14:16

AW: IBTable.Locate funktioniert nicht bei FB Dialekt 3
 
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


Alle Zeitangaben in WEZ +1. Es ist jetzt 01:34 Uhr.
Seite 1 von 3  1 23      

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz