Infosys Microsoft Alliance and Solutions blog

« Transaction Based Pricing (TBP) has arrived!! | Main | Future of Desktop Computing »

Time to bid adieu to .Net Oracle Provider

Till date I have came across several .Net implementations, where design decision to use right provider to connect to Oracle database is not given enough thought. The repercussions of this are visible as late as in Performance acceptance phase but by then it is too late to revert any design decision. The cost of fixing such design defect in acceptance can get as high from 15 to 160 times. Check here
For any .Net application development, following are the natural choices to connect to Oracle Database

1) Use native Oracle provider with .Net framework available in System.Data.OracleClient Namespace
2) Use 3rd party Providers like Oracle Data Provider(ODP), DataDirect, Openlink or Devart
While this blog doesn’t intend to compare them, a high level guideline on when to use what has been..

If you are developing application with .net 3.5 or earlier version, and if your application exhibits some of following characteristics like it is using very basic Oracle Server features, application has relatively small user base (<50), less no. of concurrent users (<10), has very limited Scalability and Performance, needs no explicit Performance Acceptance then the recommendation used to be is to go with System.Data.OracleClient, whereas if your application demands high-end scalability and performance, need to leverage latest ORACLE Server (Oracle 11g) features like support for complex data types, passing arrays, support for Real application clusters(RAC),  Creating and Monitoring Connection pools, caching statements and queries, and more mentioned here, then use ODP as it catches up relatively faster to implement support for ORACLE Server features than anybody else and also tuned for maximum scalability and performance.

Enterprise Library 4.1 doesn’t support ODP through its Data Access application block, but it can be extended to make use of it. Having said this, all the 3rd party providers have slight deployment license cost associated with it, which is justified with the mileage it provides as compared to native .net Oracle provider

With release of .Net 4.0 Microsoft will be deprecating System.Data.OracleClient which means the namespace will be available in 4.0 but not recommended to be used. In case of using it in 4.0 application development, it would throw certain compile time warnings in development environment (not runtime errors or warnings and hence fine in production). However, application implementation in .net 3.5 or less should have a plan to migrate data access implementation using System.Data.OracleClient with 3rd party providers as Microsoft support for it would stop 10 years from 4.0 release.

What it means is Microsoft is straight away recommending, start using 3rd party Oracle Providers and stop using System.Data.OracleClient for fresh development. This will not only impact bespoke Web and Windows based .Net application but also Business Intelligence application (especially SQL Server Integration Services based) development on Oracle.

With this decision, Microsoft seem to have given up the interest in making further investments in rolling out System.Data.OracleClient with any new features in Oracle Server. This decision of Microsoft will surely hit Developers and Clients who were good with using the Out of the box framework supporting plain vanilla Oracle features. Architects should be at benefit that they will have one less option to choose from J

Not sure if this decision of Microsoft will go well with all stakeholders, to stay updated keep following this

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter