Lokalisierungsproblem? bei TO_CHAR-Fkt.

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

Zitat von jobo (Beitrag 1171722)

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

Ich habe ja auch nirgends das Gegenteil behauptet :zwinker:

[jobo]

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

Der Anfang eine rekursiven Diskussion. :stupid:

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. :thumb:

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.

[jobo]

Zitat:

Zitat von Jumpy (Beitrag 1171672)

SQL-Code:

Select
TRIM(TO_CHAR(BETRAG_EU,999999999999990.99)) AS WERT
From
TABELLE

Ich hab was wichtiges übersehen, die Funktion oben verwendet eine falsche Notation. Die Format Maske gehört in Anführungsstriche. Ist das im Echtsystem auch so?

Was da in diesem Fall genau geschieht, kann ich nicht richtig nachvollziehen, aber auch hier wird offenbar implizit (falsch) konvertiert und zwar die Formatmaske selbst von Zahl zu Text.

Hier mal ein paar Beispiele:

Code:

Connected to Oracle Database 10g Release 10.2.0.2.0 
Connected as jo@db
 
SQL> 
SQL> -- my nls
SQL> select * from nls_session_parameters;
 
PARAMETER                      VALUE
------------------------------ ----------------------------------------
NLS_LANGUAGE                   GERMAN
NLS_TERRITORY                  GERMANY
NLS_CURRENCY                   ¿
NLS_ISO_CURRENCY               GERMANY
NLS_NUMERIC_CHARACTERS         .,
NLS_CALENDAR                   GREGORIAN
NLS_DATE_FORMAT                dd.mm.yyyy
NLS_DATE_LANGUAGE              GERMAN
NLS_SORT                       GERMAN
NLS_TIME_FORMAT                HH24:MI:SSXFF
NLS_TIMESTAMP_FORMAT           DD.MM.RR HH24:MI:SSXFF
NLS_TIME_TZ_FORMAT             HH24:MI:SSXFF TZR
NLS_TIMESTAMP_TZ_FORMAT        DD.MM.RR HH24:MI:SSXFF TZR
NLS_DUAL_CURRENCY              ¿
NLS_COMP                       BINARY
NLS_LENGTH_SEMANTICS           BYTE
NLS_NCHAR_CONV_EXCP            FALSE
 
17 rows selected
SQL> -- default NLS decimal separators
SQL> alter session set NLS_NUMERIC_CHARACTERS =',.'; -- default settings
 
Session altered
SQL> Select 88.1234 as MyNumber, 999999999999990.99 as MyMasknumber,
  2         TRIM(TO_CHAR(88.1234, 999999999999990.99)) as MyExplizitConvertedNumber,
  3         to_char(999999999999990.99) as MyMaskNumberImplizitConverted
  4    From dual;
 
  MYNUMBER MYMASKNUMBER MYEXPLIZITCONVERTEDNUMBER MYMASKNUMBERIMPLIZITCONVERTED
---------- ------------ ------------------------- -----------------------------
   88,1234 999999999999 0,88                      999999999999990,99
SQL> alter session set NLS_NUMERIC_CHARACTERS ='.,';
 
Session altered
SQL> Select 88.1234 as MyNumber, 999999999999990.99 as MyMasknumber,
  2         TRIM(TO_CHAR(88.1234, 999999999999990.99)) as MyExplizitConvertedNumber,
  3         to_char(999999999999990.99) as MyMaskNumberImplizitConverted
  4    From dual;
 
  MYNUMBER MYMASKNUMBER MYEXPLIZITCONVERTEDNUMBER MYMASKNUMBERIMPLIZITCONVERTED
---------- ------------ ------------------------- -----------------------------
   88,1234 999999999999 88.12                     999999999999990.99
SQL> alter session set NLS_NUMERIC_CHARACTERS =',.'; -- Default
 
Session altered
SQL> -- do the same with corrected format mask
SQL> Select 88.1234 as MyNumber, 999999999999990.99 as MyMasknumber,
  2         TRIM(TO_CHAR(88.1234, '999999999999990.99')) as MyExplizitConvertedNumber,
  3         to_char(999999999999990.99) as MyMaskNumberImplizitConverted
  4    From dual;
 
  MYNUMBER MYMASKNUMBER MYEXPLIZITCONVERTEDNUMBER MYMASKNUMBERIMPLIZITCONVERTED
---------- ------------ ------------------------- -----------------------------
   88,1234 999999999999 88.12                     999999999999990,99
SQL> alter session set NLS_NUMERIC_CHARACTERS ='.,';
 
Session altered
SQL> -- do the same with corrected format mask
SQL> Select 88.1234 as MyNumber, 999999999999990.99 MyMasknumber,
  2         TRIM(TO_CHAR(88.1234, '999999999999990.99')) MyExplizitConvertedNumber,
  3         to_char(999999999999990.99) as MyMaskNumberImplizitConverted
  4    From dual;
 
  MYNUMBER MYMASKNUMBER MYEXPLIZITCONVERTEDNUMBER MYMASKNUMBERIMPLIZITCONVERTED
---------- ------------ ------------------------- -----------------------------
   88,1234 999999999999 88.12                     999999999999990.99
 
SQL>

[Jumpy]

Der Formatstring war tatsächlich ohne Gänsefüßchen.
Das ist mir vor lauter Länge gar nicht aufgefallen.

Auch wenn nicht erklärbar ist, was da falsch läuft (sprich die verschiebung der Nachkommastellen) zeigt dein Beispiel, dass bei korrektem Formatstring die Änderung der Lokalisierung tatsächlich nur Komma und Punkte vertauscht und nicht für die Verschiebung der Nachkommastelle verantwortlich ist.

Danke für die Zusatzinfo.:thumb:

[jobo]

Fakt ist, der Funktionsaufruf ist in der Form as P#1 falsch. Warum das von Oracle ohne Fehlermeldung geschluckt wird, kann ich nicht verstehen.

Der falsch typisierte Parameter wird also offenbar auch konvertiert (von Zahl zu Text), das kann nur zufällig gut gehen, wenn nämlich der Parameter (eigentlich Formatmaske) keine Aplha Zeichen enthält.

So oder so, implizite Typkonvertierung ist ein Graus. Wenn es das nicht gäbe, wären aber wahrscheinlich 50% der Datenbankentwickler arbeitslos.
:)

[Jumpy]

Zitat:

Zitat von jobo (Beitrag 1171918)

Der falsch typisierte Parameter wird also offenbar auch konvertiert (von Zahl zu Text), das kann nur zufällig gut gehen, wenn nämlich der Parameter (eigentlich Formatmaske) keine Aplha Zeichen enthält.

Ist so. Hab aus Neugier nochmal rumgespielt.

Aus TO_CHAR(12122.22,999990.99)
wird TO_CHAR(12122.22,TO_CHAR(999990.99))
wird bei dt. Lokalisierung zu TO_CHAR(12122.22,'999990,99'))

Bleibt die Frage, warum er dabei aus dem Ergebnis 121,22 macht, anstatt 12122,22. Es findet da auch eine Rundung statt: 12122.82 wird zu 121.23.
Bei '.' oder 'D' an der Stelle des Kommas "wird alles gut".