Weeeeelll phooey.
I appreciate the help, though.
"Mary Chipman" wrote:
> 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
>
> On Mon, 17 Jan 2005 14:19:05 -0800, David Jessee
> <(E-Mail Removed)> wrote:
>
> >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.
> >
> >"Mary Chipman" wrote:
> >
> >> 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
> >>
> >> On Sun, 16 Jan 2005 13:19:01 -0800, David Jessee
> >> <(E-Mail Removed)> wrote:
> >>
> >> >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.
> >> >
> >> >
> >> >
> >> >"Mary Chipman" wrote:
> >> >
> >> >> 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
> >> >>
> >> >> On Sat, 15 Jan 2005 08:51:01 -0800, David Jessee
> >> >> <(E-Mail Removed)> wrote:
> >> >>
> >> >> >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?
> >> >>
> >> >>
> >>
> >>
>
>
|
Similar Threads
