Du hast also in Deiner Tabelle Zahlen als Strings gespeichert, z.B. '6,91'.
Wenn Du jetzt in der Prozedur diesen String in eine Zahl umwandelst, richtet sich Oracle nach den Ländereinstellungen des DB-Servers.
Nachdem Oracle 6,91 als gültige Zahl interpretiert, sind dort alse die Einstellungen für Deutschland aktiv. Oracle wandelt also den String '6,91' in die Zahl 6,91 um. Jetzt gibst Du diese Zahl als Parameter an das aufrufende Programm zurück. Delphi bekommt also 6,91 als Ergebnis. Dies ist für Delphi aber keine gültige Zahl, um keinen Fehler zu erhalten, müsste das Ergebnis 6.91 lauten. Das wiederum kann Oracle aber nicht als Zahl liefern, ohne dass Die Serverumgebung auf amerikanische Zahlenformate eingestellt wird.
Falls Du diesen Wert in der Stored Procedure nicht weiterverarbeitest, kannst Du ihn als String auslesen und in einem String-Parameter an Delphi übergeben. Hier kannst Du den Wert in eine Zahl umwandeln.
Falls Du mit dem Wert auch in Oracle rechnen musst, könntest Du ihn mit TO_CHAR wieder zurückverwandeln.
Dieses Problem hast Du übrigens auch, wenn Du Daten von Oracle (deutsch) nach MS Access (deutsch) und umgekehrt exportierst. Obwohl ein deutsches Access Zahlen mit Komma darstellt, verwendet Microsoft intern den Dezimalpunkt. Deshalb werden Gleitkommazahlen bei der Konvertierung immer in Strings umgewandelt, da sich beide Datenbanken mit ihrem Zahlenformat nicht verstehen.
