Approximating Decimal Type consistency from DB to .NET

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I was wondering if anyone's run against this.....
You have your numeric types on your database (SQL-decimal, Oracle Numeric)
and then you have the data types in .NET

I really don't want to have to sit down and check out the data types from my
database, then have to map them to .NET types (e.g. single vs double). Is
there any way yo determine the mapping? I know you can perform a SQL select,
do a fill schema on a data table and see what the provider does for mapping,
but I'm looking for somethign a little more direct.

Any Ideas?
 
Have you checked out the System.Data.OracleClient.OracleType
enumeration topic in the Help file? You can explicitly map the data
types yourself if you want more control. I'm not sure what you mean by
"something a little more direct".

--Mary
 
Well, what it comes down to is that if I have a numeric type in a database
(not necessarily Oracle) that has a given precision and scale. I have to
sit and think which data type would be most appropriate for that value in
..NET single, double, int32, etc.

I was wondering if there was a mor intrinsic way of doing that.

I could do a sql select statement, then do a fillSchema on a datatable and
see which data types .NET inferrs for those fields, but that's a more obtuse
way of determining type mapping.
 
If you're working with SQL Server, it's a lot easier because you can
use SqlTypes, which map directly to SQL Server data types, without
having to rely on conversions to CLR types (implicit or otherwise). If
you have precision and scale to worry about, then the CLR decimal or
SqlDecimal is what you want to go with. In ADO.NET 2.0, you'll be able
to explicitly define DataSet/DataTable columns using SqlTypes, but of
course that won't work for Oracle. You're better off figuring out the
data types ahead of time rather than doing a fillschema because it
entails an extra round trip to the database, negatively impacting
performance and scalability.

--Mary
 
Well, here's the thing, I really do not want to use the SqlTypes because that
ties you to a database scenario.

We don't pass datatables to the ASP.Net pages that we use. We stick with an
Invoice Class, Customer Class, etc. When creating these classes, we use the
primitive .NET types, that way the class is only concerned with its
information an behavior.

We've also created an object-relational mapping model so that we don't have
to worry about creating our Data Access Layer.

To Date, we've been using numeric types in the database that directly
reflect the native .NET types since the model drives the data. Howevever,
there could be benefits from using precisions that are more customized.
 
At this point I think you're just going to have to add the customized
data type handling to your DAL. It's difficult to standardize when you
have to work with multiple RDBMS platforms, each with it's own way of
handling decimal and numeric data, and the CLR types basically have to
play to the lowest common denominator. The only built-in customization
is for SQL Server with SqlTypes, which is natural considering that
it's a msft product :-)

--Mary
 
Back
Top