Dezimalwerte per ODBC von ACCESS an ORACLE (Spracheinstellungen)

[webrookie]

Moin aus dem Norden,

ich habe eine Oracle APEX-Anwendung, die in einigen Tabellen Dezimalwerte z.B. 17,38 abspeichert.
Zusätzlich besteht eine Schnittstelle via ODBC zu einer ACCESS-Anwendung.

Der Oracle-Server hat als Spracheinstellung Englisch.

Die ACCESS-Anwendung wird auf verschiedenen Clients mit unterschiedlichen Betriebssystemen genutzt.
Nun ist es so, dass einige Clients ein englisches Betriebssystem (Windows XP) mit adaptierter deutscher Oberfläche
und andere ein echtes deutschsprachiges OS (Windows XP oder Windows 7) nutzen.

Bei Übergabe der Dezimalwerte von ACCESS zu ORACLE wird unabhängig von den Regionaleinstellungen die
Function (TO NUMBER) unterschiedlich ausgewertet.

In der Zieldatenbank werden die Dezimaltrenner (unabhängig von der Clientdarstellung) beim "deutschen" OS ignoriert, so dass
aus dem Character "17,5" oder "17.5" ein Number "175,0" wird.

Auch eine Auswertung der Quell- und Zielspracheinstellung hat nicht zum gewünschten Erfolg geführt.

Gruß

Richard

[defo]

Und jetzt sollen wir die Frage raten?

Was genau ist die

Übergabe der Dezimalwerte von ACCESS zu ORACLE

Eine handgestrikte Query, ein Script, ..?

[Jürgen Thomas]

defo hat natürlich völlig recht mit seinen Nachfragen. Unabhängig davon klingt die Beschreibung so, als ob die Werte nicht als numerische Werte, sondern als Strings übergeben und verarbeitet werden. Das wäre ziemlicher Blödsinn. Für .NET gibt es eine Beschreibung der Probleme und Lösungen unter SQL: Parameter von Befehlen. Aber auch für alle anderen Entwickler und Anwendungen gilt der Grundsatz: Daten sind immer im ursprünglichen Datentyp zu verarbeiten und dürfen nicht als String hin- und herkonvertiert werden. Jürgen

[webrookie]

Lösung gefunden!

create or replace function "XV$FU_TO_NUMBER"
(p_number in VARCHAR2,
 p_format in VARCHAR2
)
    return NUMBER
is
   v_helper varchar2(10);
   v_session_nls_chars VARCHAR2(20);
begin

    select value into v_session_nls_chars from nls_session_parameters where parameter = 'NLS_NUMERIC_CHARACTERS';

    if substr(v_session_nls_chars,1,1) = ',' then
        -- Die Session ist auf Dezimalwerte mit Komma eingestellt.
        -- Dann muessen wir einen Dezimalpunkt durch ein Komma ersetzen
        v_helper := translate(p_number,'.',',');
    else
        -- in allen anderen Faellen ersetzen wir ein Dezimalkomma
        -- durch einen Dezimalpunkt
        v_helper := translate(p_number,',','.');
    end if;
   

    return to_number(v_helper, p_format);

    exception when OTHERS then return 0;
end;

[Bernhard Geyer]

Bedenke auch den tausender-Trennzeichen-Fall

1.000.000,10 -> 1,000,000,00

[webrookie]

Bedenke auch den tausender-Trennzeichen-Fall

1.000.000,10 -> 1,000,000,00

Danke, ist jedoch im Vorfeld schon ausgeschlossen, da in meiner Db betroffenen Werte nur kleiner 999,99 sein können und dürfen.

[defo]

Danke, ist jedoch im Vorfeld schon ausgeschlossen, da in meiner Db betroffenen Werte nur kleiner 999,99 sein können und dürfen.

Dann hoffe ich mal für Dich, dass niemand diese praktische Funktion in einem anderen Zusammenhang nutzt und Du Dich selbst noch in 6 MOnaten daran erinnerst.
Eine Bereichstprüfung mit Fehlerbehandlung wäre hier sinnvoll.

[jum]

In der Funktion "XV$FU_TO_NUMBER" (muss übrigens groß geschrieben werden), wird der Parameter p_format nach Prüfung an die Funktion to_number(v_helper, p_format) unverändert "durchgereicht".
Diese Funktion hat aber eigentlich drei Parameter:

TO_NUMBER(text-exp, [fmt,] [nlsparams])

Das ist etwas inkonsequent...
Kritisch sehe ich auch, dass in jedem Fehlerfall einfach 0 zurückgegeben wird.
Aber wenn die Quelldaten schon im Vorfeld geprüft/eingeschränkt wurden mag das gehen.

Viel Erfolg