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.

[jobo]

Bevor Du "alles" umstellst, mach doch ein paar Tests.
Nicht nur, ob dass dann mit dem Zugriff im Client funktioniert wie gewünscht, sondern auch DB seitig Dinge wie Referential Constraints auf dieses Feld.
Die Angabe von Char statt Byte ist sinnvoll, würde ich aber ebenfalls auf ihre Auswirkungen testen. Sinnvoll wäre es jedenfalls, wenn es Richtung Unicode geht. Bedeutet aber für alle derart definierten Spalten eine Vergrößerung des Speicherplatzbedarfs.
So oder so, es macht sich sicher bezahlt, hier mal genauer hinzuschauen, bevor man "drauflos " umstellt.

[mlc42]

Es lag tatsächlich am varchar2. Wenn man mal die Emba Bespiele zu Oracle genau anschaut, verwenden
die auch immer varchar2. Wieder was gelernt.

Mein gesamtes, recht komplexes, Programm läuft damit, so wie es im Moment aussschaut, einwandfrei.
Die Strukturänderung ist für mich sehr einfach, weil an einer Stelle in unserem DB Kopiertool nur
der Typ geändert werden muss. Mal schauen ob mir noch Ungereimtheiten auffallen.

Danke nochmal für den sehr wertvollen Tip.

[Bernhard Geyer]

Zitat von mlc42:

Es lag tatsächlich am varchar2. Wenn man mal die Emba Bespiele zu Oracle genau anschaut, verwenden
die auch immer varchar2. Wieder was gelernt.

Die "alten" Datentypen char sind ein "überbleibsel" aus den Kindertagen der Datenbanken.
Die ersten Implementierungen hatten nur Zeichenketten mit automatischer Füllen.
Da dies sehr unpraktisch war hat man über die Jahre die varchar-Typen eingeführt. Und diese sollte man nur noch verwenden.
char ist in den seltensten Fällen sinnvoll.

[himitsu]

Jupp, Chars ist wirklich nur für Texte mit fester länge nutzbar.

z.B. für Hashs, welche immer genau eine bestimmte Länge besitzen.