How to format OracleNumber generically

Question

I built a small query tool for Oracle with CSV export function with an OracleDataAdapter to fill a dataset that is displayed in a DataGrid (WinForms). At first I used .NET types (DateTime, decimal, string,...) but I got overflow exceptions in some cases because of larger precision in Oracle (NUMBER(30,10)). Therefore I had to set the property ReturnProviderSpecificTypes = true in the OracleDataAdapter so now it uses OracleClient (OracleNumber, OracleBoolean, OracleString,...) types instead.

The problem is everything is always localized (on screen and during CSV output) to en-US formats while I'm in nl-BE region (we use comma as decimal separator and point as thousand separator). The column separator in CSV is semicolon btw, so there's no interference with the comma in decimal numbers.

So is there a way to override the ToString method in a way for those types? Some sort of injecting a formatting engine?

Thanks

Answer 1

You can use ALTER SESSION SET NLS_.... Look: http://download.oracle.com/docs/cd/B28359_01/olap.111/b28126/dml_options072.htm

There is example of how it works with dot ad decimal point and space as thousand separator (also note datetime setting):

alter session set NLS_NUMERIC_CHARACTERS='. '
alter session set nls_date_format='YYYY-MM-DD HH24:MI:SS'

Answer 2

Seems like there is no good generic way to do this. For the CSV output I found a workaround but not for the output on screen.

During output I have to test every value for type OracleNumber (I have to test for INullable anyway) and cast it accordingly. Then there are two options:

// Replace: not clean and could be a heavy operation
writer.Write(myOracleNumber.ToString().Replace('.', ','));

or

// Returns decimal but result is not exact (which is acceptable in my case)
writer.Write(OracleNumber.Round(myOracleNumber, 10).Value);

For output on screen we could use a similar technique and load a new DataTable in memory from the one filled by the OracleDataAdapter but then with .NET CLR types, but since the resultsets could be very large, that could be a dangerously heavy trick to do, so we'll just live with english notation there...