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 :
)