How does Oracle JDBC thin driver handle numbers via getString?

Question

Hi,
I have a query regarding how numbers are handled by the oracle jdbc thin driver. The issue I am facing is with regards to the decimal separator (. is en_US and , in pt_BR)
e.g. Consider the below code,
Connection conn = DriverManager.getConnection(...);
Statement stmt = conn.createStatement();
ResultSet rset = stmt.executeQuery("select value from test_table1");
while (rset.next())
System.out.println (rset.getString(1));
test_table1 has a single column of sql type 'number' with a single row having value "123.45"
NLS_NUMERIC_CHARACTERS = ".,"
Database version = 10.2.0.2.0
There is a (generic) method to which a ResultSet is passed and it returns a dictionary of key value pairs. All column values from the ResultSet are retrieved using getString method of ResultSet.
My question is whether the jdbc driver formats numbers (based on the locale) before returning it as a string as part of the getString method?
e.g.
java -Duser.language=pt -Duser.region=BR TestJDBC
prints "123.45" and not "124,45"
Is there a reason why getString always retrieves a number column value with '.' as the decimal separator?
To help make things a bit more clear, all the column values retrieved are then converted into an XML (and hence the conversion to string)
At present, the only way I see out of this is to handle numbers differently.
i.e. something similar to,
if (resultsetmetadata.getcolumntype .. = double OR float OR int OR long.. )
NumberFormat.getInstance().format(rset.getDouble(1));
Is there a better way to resolve this issue?
Thanks,
Binoy

Answer 1

user565580,
As has been already stated, Oracle does not have data-types INTEGER or SMALLINT, only NUMBER.
So even though Oracle lets you write INTEGER, it really creates a NUMBER.
(As Joe mentioned.)
Other databases don't have a NUMBER data-type, they have INTEGER, SMALLINT, etc.
Originally, Oracle database only had three data-types:
CHAR
DATE
NUMBER
If you're going to be working with Oracle database, then you need to adapt yourself to its limitations.
So you'll probably need to define NUMBER data-types using scale and precision.
(As Kuassi mentioned.)
Good Luck,
Avi.