Lokalisierungsproblem? bei TO_CHAR-Fkt.

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