FireDac Oracle Param Abfrage mit String

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