Oracle: column = 'N' geht nicht, column <> 'J' geht???

[Phoenix]

Zitat von Elvis:

bessere Lösung: Unicode für alle Maschinen als Default CharSet benutzen.

Hrm. Das wird schwer. Soweit haben wir auf die IT des Kunden wohl keinen Einfluss. Dann also lieber direkt mit TRIM() arbeiten.

Aber das erklärt nicht, warum ein <> funktioniert - denn wenn ein 'N' schon nicht 'gleich' 'N' ist, ist es doch 'ungleich' 'N' und müsste konsequenterweise bei einem <> auch mitgeliefert werden. Sehr Strange...

[Elvis]

Ist ja alles schön und gut, aber was sagt SQL+ ?

[Phoenix]

Zitat von SQL*Plus:

Es wurden keine Zeilen ausgewählt

[dfried]

Zitat von Elvis:

@dfried
Nope, Trim ist eine Art compiler magic, die nicht nur für CLob und VarChar existiert. Packst du NVarChar rein wirst du auch NVarChar rauskriegen.
Wäre ja schlimm, wenn man keine Unicode-Werte trimmen könnte.

Hm, also mein ORA-Doku (9iRel2) sagt dazu
"The string returned is of VARCHAR2 datatype and is in the same character set as trim_source."

[Elvis]

Zitat von dfried:

Hm, also mein ORA-Doku (9iRel2) sagt dazu
"The string returned is of VARCHAR2 datatype and is in the same character set as trim_source."

Pah, alles was nach Ora 8.0 in den Docs hinzu kam (oder neue Overloads zu bestehenden Funktionen), sollte man mehr als vorsichtig betrachten.
Trim kann zum Beispiel auch auf einem CLob angewendet werden, wobei das Ergebnis wieder ein CLob ist.
Genau wie ein NVarChar-Parameter ein NVarChar-Ergebnis bringt.

Wobei der Trim-Workaround fürcterlich weh tut.

Große Frage an Phönix:
Tritt das nur bei Single char-Feldern auf? Wenn ja, kannst du sie zu single byte VarChar/Char(1) ändern?

Warum ist dieses 'J'/'N'-Feld überhaupt ein NVarChar(1) anstatt einem normalen Char(1)?

Und wenn du auf eine Funktion angewiesen bist, nimm lieber SubStr(x, 1, 1). Das wäre wesentlich sparsamer als Trim.

[Phoenix]

Hrm.. sagen wir es so: Aus wenn es ein NVarChar2(x) ist, geht es nicht. Ein Vergleich auf eine längere Zeichenfolge (z.B. Abfrage nach Matnummer = '123456' oder Auftragsnummer = '11.111.111') funktioniert hingegen einwandfrei.

Das Umwandeln in einen Char(1) muss ich mal probieren wenn ich am Samstag wieder beim Kunden sitze.

Hrm.. Trim() sieht aber schöner im Code aus als Substr(NAME, 1, 1)

Das mit dem NVarChar war aus dem Hintergrund geboren, dass die restlichen Strings alle Unicodefähig sein müssen, weil die, die das Programm hinterher verwenden _sehr_ International ausgerichtet arbeiten. Und sollten die auf die Idee kommen ihr 'Ja' / 'Nein' auf einmal Chinesisch oder Japanisch oder Russisch oder wie auch immer darzustellen sollte das eigentlich drin sein... Naja, das wird kein Hinderungsgrund für eine Abnahme sein, aber es ist einfach unschön.

Ich meine, ich könnte ja auch einfach auf != umschwenken - da gehts ja seltsamerweise...

[Elvis]

Zitat von Phoenix:

Hrm.. Trim() sieht aber schöner im Code aus als Substr(NAME, 1, 1)

Nanana, nicht dass ich hier noch Überschneidungen mit Benutzern einer Sprachen mit den Buchstaben B & V suche.

Zitat:

Das mit dem NVarChar war aus dem Hintergrund geboren, dass die restlichen Strings alle Unicodefähig sein müssen, weil die, die das Programm hinterher verwenden _sehr_ International ausgerichtet arbeiten. Und sollten die auf die Idee kommen ihr 'Ja' / 'Nein' auf einmal Chinesisch oder Japanisch oder Russisch oder wie auch immer darzustellen sollte das eigentlich drin sein...

Es gibt viele Wege um sein Ziel zu erreichen. Ja/Nein in die DB zu schreiben und sich plötzlich mit Lokalisierung auseinanderzusetzen dürfte wohl unter "über Berlin von Nürnberg nach München fahren" laufen. 0 oder 1 würden es ja auch tun (wären sogar elegant in einen Boolean zu wandeln ohne dass eine String Instanz im DAL erzeugt werden müsste).
Ich versuche normal die Größe eines Records so klein wie möglich zu halten. Sinnlos mit multibyte Strings oder Strings im Allgemeinen um sich werfen ist IMHO nicht so sinnvoll.
OTOH, wirkliche Strings als Unicode abzulegen ist hingegen mehr als sinnvoll. Heutzutage kein Unicode zu benutzen ist schon grob fahrlässig, IMHO.

Zitat:

Ich meine, ich könnte ja auch einfach auf != umschwenken - da gehts ja seltsamerweise...

Du wirst lachen, aber meine erhöhte Antwortfrequenz heute liegt auf einer anderen verfluchten Macke in Oracle begründet, wegen der ich praktisch nix machen konnte.
Waren allerdings pipelined functions. Aber es ist immer wieder traurig wie hirnrissig die Macken mit jeder neuen Ora Version werden. (Wenn man sieht wie viel Kohle dafür über den Tisch wanderte : )