FireDac Oracle Param Abfrage mit String

[mlc42]

Hallo,

ich habe eine seltsamen Effekt. Alle Master/Detail Beziehungen in meinem Programm
die mit Params als Stringtyp angegeben sind, arbeiten unter Oracle nicht. Die Detailmenge bleibt
immer leer. Der gleiche Code funktioniert unter Firebird, MSSQL und Postgre einwandfrei.

Ein einfaches Beispiel FDConnection, FDQuery etc. auf ein Form und im SQL Designer z:B: eingeben

select * from tabelle where p.nummer = '1000' gibt die korrekte Datenmenge zurück.

mit

select * from tabelle where p.nummer = :pnum und pnum auf '1000' setzen,
kommt immer eine leere Datenmenge zurück.

Mit Integerparams geht das einwandfrei. Das Feld ist in der Tabelle mit char(16 byte) definiert.
Ich verwende nur Ansistring kein UTF (auch in der DB)

Das Verhalten tritt unter der aktuellen Tokyo und auch in einer alten Delphi2007 Maschine mit einer
der ersten FireDAC Versionen auf.

Ich bin für jeden Tip dankbar.

Martin

[mkinzler]

Versuch mal

select * from tabelle where TRUNC(p.nummer) = :pnum;

[jobo]

Zitat von mlc42:

Mit Integerparams geht das einwandfrei. Das Feld ist in der Tabelle mit char(16 byte) definiert.

CHAR wird in Oracle mit leerzeichen bis zur definierten Feldgröße aufgefüllt.
So einen Type sollte man am besten nur verwenden, wenn er immer "voll" ist, also hier ein 16stelliger Text reinkommt.

Eigentlich wird er normalerweise nicht mehr verwendet.

Um den Vergleich richtig zu machen müsstest Du das gleiche mit Deinem Parameterwert machen (Leerzeichen anhängen).

Das es mit diversen impliziten oder expliziten Konvertierungen doch zu einem Ergebnis kommt, würde ich als Seiteneffekt bezeichnen. Der wird nicht mehr helfen, wenn tatsächlich mal ein Buchstabe im String stünde (oder wofür ist das als Char definiert?)

Der Vorschlag mit Trunc, sowie ähnliche Verfahren brechen die Nutzung eines Index und sind damit nur hilfreich, wenn ein Index nicht benötigt wird.

[Delphi.Narium]

Und Trunc funktioniert nur, bis der erste Buchstabe bzw. die erste "Nichtziffer" (egal auf welcher Seite) kommt. (Und bei der dann auftretenden Fehlermeldung möchte ich nicht nach der Ursache suchen müssen, denn die Wahrscheinlichkeit, da sie auf Anhieb plausibel erscheint, dürfte eher gegen 0 tendieren.)

Dann doch lieber mit Trim und Index adé.
Oder RTrim, falls es mal mit Leerzeichen anfangen sollte.

Literatur dazu: CHAR versus VARCHAR2 Semantics

[mlc42]

Danke für die Tips

ich werde dann mal meine Tabellen auf varchar2 umstrukturieren. Vielleicht hilft das ja.
Seltsam nur das das nur bei Param auftritt.
Trunc würde in der Tat nicht funktioneren, weil die Kunden in diese Felder auch Alphazeichen
eingeben, daher die Wahl von Char.

[Bernhard Geyer]

Und nimm bei der längenangabe auch gleich char statt byte.
Ein Oracle 8 wirst du wohl nicht mehr unterstützen müssen und mit Sonderzeichen außerhalb Ascii-7 Bit willst du sicherlich auch keine Längenprobleme bekommen.