Lokalisierungsproblem? bei TO_CHAR-Fkt.

[jobo]

Erzwingen kann man es zur Laufzeit, also innerhalb der Anwendung durch Absetzen von:

Code:

alter session set NLS_DATE_FORMAT = 'dd.mm.yyyy';

usw.

Wenn die Connection in der Anwendung geschlossen und geöffnet wird, muss man es wiederholen.
Wie gesagt, die NLS Settings können auf 3 Ebenen gesetzt werden. Server, Client[installation] (also Registry unter windows) und Session. Letzte Instanz ist die Session, die ist allerdings flüchtig. Alles was fehlt oder nicht angegeben ist, wird ausgehend von den Serversettings verwendet.

Das Displayformat im Client hilft bei der to_Char Funktion nicht, da es sich innerhalb von Oracle abspielt.

Nachtrag:
Die NLS Settings definieren alle sprachabhängigen Darstellungen, länderspezifisch. Wird auch (bei anderen Anbietern) als locale settings o.ä bezeichnet. Das hat mit dem OS überhaupt nichts zu tun, es ist komplett unabhängig, allerdings nimmt der Installer die Einstellungen des Wirtsystems als Vorgabe. Eine Installation des Servers auf einem deutschen Windows ergibt also andere NLS Settings als auf englischen Servern, ebenso beim Client.
Man kann es aber alles verstellen.

[DeddyH]

Falls ich das richtig verstanden habe, wird das TO_CHAR ja nur verwendet, um ein bestimmtes Ausgabeformat zu erreichen. Wenn man das aber clientseitig macht, kann man sich das sparen und einfach den Originalwert abfragen.

[jobo]

Klar, wenn man auf das to_char verzichtet, kann man es im Client erledigen. Das ist eine Geschmacksfrage oder abhängig vom Anwendungsfall.
Es schadet aber auch nicht, zu wissen, was die NLS Settings sind. Sie kommen z.B. bei jeder impliziten Typkonvertierung von Zahlen und Datumswerten ins Spiel und können böse weh tun, wenn man ihr Verhalten bzw. unterschiedliche client setups ignoriert.

[DeddyH]

Zitat von jobo:

Es schadet aber auch nicht, zu wissen, was die NLS Settings sind.

Ich habe ja auch nirgends das Gegenteil behauptet

[jobo]

Ich hab ja auch nirgends behauptet, dass Du behauptet hast, dass ..

Der Anfang eine rekursiven Diskussion.

Also ernst, NLS Settings oder Lokalisierung von DB und Clients allgemein, kann in der Bedeutung sehr leicht unterschätzt werden. Meine Betonung dieses Problems galt nicht Dir, sondern schlicht allen Datenbankentwicklern auf der Welt.

[Jumpy]

Clientseitig ist da nix zu machen, weil das eine Verarbeitung ist, die große SQl-Statements jeweils aus einer Datei lädt an die DB schickt. Da werden auf Selects basierend neue Tabellen erstellt, worauf dann spätere SQL-Statements zugreifen und Selects erzeugen, die dann letztlich zurückgeliefert werden und die dann direkt von der Query in eine CSV geschrieben werden. Es ist daher nicht bekannt, welche Felder es gibt und welche Felder ggf. in dem Format kommen, das bearbeitet werden müsste. Daher ist clientseitig in der Anwendung da nichts machbar.

Problem ist ja prinzipiel gelöst, nachdem die NLS Settings in der Registry angepasst wurden. Ist aber für mich eine Lehre gewesen, so dass meine zukünftigen ähnlichen Verarbeitungen zunächst die Settings checken und dann Meldung machen, falls diese falsch sind. Mit jobo's Tip kann die Verarbeitung aber dann trotzdem mit temporären Settings weitermachen, bis mal einer dazukommt, den entsprechenden Rechner richtig einzustellen.

Nur aus Neugier aber immer noch die Frage:
Gibt's ein eleganteres Konstrukt zur Erzwingung von Nachkommastellen. Was ich so gegoogelt habe muss immer irgendwie eine konvertierung in einen "String" stattfinden durch sowas wie Format und das ist ja in Oracle To_Char. Die Cast-Funktion tut's da (in Oracle) auch nicht, in anderen DB's soll's da mehr Möglichkeiten geben.