Lokalisierungsproblem? bei TO_CHAR-Fkt.

[jobo]

Zitat von Jumpy:

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.

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

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