System.Data.OracleClient Update
As a part of formulating our long term strategy for ADO.NET, we have had several discussions with number of our customers, internal and external partners, and MVPs to better align our development efforts to ensure we are delivering the right technologies according to our customers’ highest priority needs. One of the key intent of these discussions and the associated research was to understand the needs and requirements of customers who develop applications with Oracle using “System.Data.OracleClient” (OracleClient). OracleClient is the ADO.NET provider for Oracle developed by Microsoft and ships as a part of the .NET Framework.
We learned that a significantly large portion of customers use our partners’ ADO.NET providers for Oracle; with regularly updated support for Oracle releases and new features. In addition, many of the third party providers are able to consistently provide the same level of quality and support that customers have come to expect from Microsoft. This is strong testament of our partners support for our technologies and the strength of our partner ecosystem. It is our assessment that even if we made significant investments in ADO.Net OracleClient to bring it at parity with our partners based providers, customers would not have a compelling reason to switch to ADO.Net OracleClient.
The Decision
After carefully considering all the options and talking to our customers, partners, and MVPs it was decided to deprecate OracleClient as a part of our ADO.NET roadmap.
Recommendation and Guidance:
System.Data.OracleClient will be available in the upcoming 4.0 release of .NET Framework; however, it will be marked as deprecated. This will have no impact to existing applications and these applications will continue to work as expected. Developing new applications which use OracleClient will be supported; however, warnings will be raised if the applications are compiled against .Net 4.0. Once compiled, no warnings or errors will be generated while running these applications. We strongly recommend customers to use our partners’ ADO.NET Provider for Oracle instead of continuing to use Microsoft’s OracleClient for new application development.
Microsoft will continue to provide hotfixes for critical issues in System.Data.OracleClient as per the standard support policy for .Net Framework 4.0. We will also continue to make critical bug fixes in future service packs for .Net Framework 4.0.
Thank you,
Himanshu Vasishth
Program Manager, ADO.NET OracleClient
Comments
Anonymous
June 15, 2009
PingBack from http://aspmvc.co.cc/2009/06/15/systemdataoracleclient-update/Anonymous
June 15, 2009
I have found two 3rd party providers: -http://www.datadirect.com/products/net/net_for_oracle/index.ssp -http://www.devart.com/dotconnect/oracle/ Are there others you can recommend?Anonymous
June 15, 2009
The Devart provider supports EF and these guys even made their own implementation of LINQ to SQL - it's called LINQ to Oracle. Sure it has bugs...But they fix them, really :-)Anonymous
June 15, 2009
Himanshu Vasishth acaba de anunciar en el blog de ADO.NET que para .NET 4.0 el driver de Oracle paraAnonymous
June 16, 2009
The comment has been removedAnonymous
June 16, 2009
OMG, 80% of our applications are using this provider and now you told me that i have to pay for a rubish 3rd party provider?Anonymous
June 16, 2009
@Scott, @Banker - Third party doesn't have to mean rubbish... and it often means faster fixes and feature additions, as was the case with Entity Framework support. @SteinarH - Depending on your needs, you might look into either -- http://uda.openlinksw.com/dotnet/mt/dotnet-oracle-mt/ -- or -- http://virtuoso.openlinksw.com/dataspace/dav/wiki/Main/VirtOracleEntityFrameworkUsageAnonymous
June 16, 2009
Microsoft has made a huge announcement regarding the OracleClient library in ADO.NET. Himanshu VasishthAnonymous
June 16, 2009
Microsoft deprecating Oracle Client from ADO.NET 4Anonymous
June 16, 2009
@scott: I think you'll find the latest ODP.net from Oracle works quite well. Recent feature adds: http://www.oracle.com/technology/tech/windows/odpnet/newfeatures.htmlAnonymous
June 16, 2009
VERY disappointing! The System.Data.OracleClient has been so very stable. Like @Scott, I think the OracleClient was way better than the System.Data.OracleClient. It's like having to buy 3rd Party Controls for stupid features that should be included. I also do not experience faster upgrades from my 3rd Party Vendors.. Not at all.. This is bad, bad news!Anonymous
June 16, 2009
What will be the impact of this to the Data Access Application Block ?Anonymous
June 16, 2009
Disappointed as well. The ODP.Net drivers rarely work with Visual Studio tooling, and I think still lack any support for LINQ or EF. I think Oracle has been pretty clear at not supporting anything beyond basics in .Net - the merger with Sun only makes this announcement even worse.Anonymous
June 16, 2009
@Shane, all, I've tried using ODP.Net in the past and it's been a real pain because the libraries are version specific. Must have 10g ODP.Net for 10g install, 11g for 11g, etc. I never had to worry about that with OracleClient. I tried twice to switch to ODP (for the additional features) and gave up because of the versioning issues.Anonymous
June 16, 2009
The comment has been removedAnonymous
June 16, 2009
We try many third part providers. Yes it have more features then OracleClient, but very unstable. We try use ODP.NET provider from Oracle, but ODP has problems with support and serious memory leaks then work with clobs. As result we return to OracleClient and happy with him... We have more then 10 products what use OracleClient and not have a problems. Very bad news :(Anonymous
June 16, 2009
The comment has been removedAnonymous
June 16, 2009
This seems short sighted to me. I have found integrating between an existing Oracle database and new .NET code very straightforward using the OracleClient. We do not have a big budget and purchasing a third party tool is not a good option for us. Disappointing news.Anonymous
June 16, 2009
The comment has been removedAnonymous
June 16, 2009
Microsoft deprecates its ADO.NET Oracle provider (System.Data.OracleProvider)Anonymous
June 16, 2009
For those concerned about having to pay for third-party providers, ODP.NET is free to use for development and deployment. As a previous poster indicated, multiple ODP.NET versions can exist on the same machine with each .NET app using a different ODP.NET version. This enhancement was introduced starting in ODP.NET 10.2.0.4. This feature should overcome some of the previous posters' complaints about multiple ODP.NET versions co-existing. If you have specific issues with ODP.NET, feel free to email me alex.keh {at} oracle.com.Anonymous
June 16, 2009
Any chance you could throw the code up on CodePlex and let the community have at it?Anonymous
June 16, 2009
The ADO.NET Oracle client isn't about giving "customers ... a compelling reason to switch." It's about .NET developers who don't already have an investment in a third-party provider. If I'm an in-house developer creating a small intranet application that has to run against Oracle, I don't want to have to research Oracle providers and battle the purchasing process and figure out the deployment issues. I want to use what's in the framework. Sure, Oracle power users will probably want ODP.NET or DevArt or DataDirect for their extra performance and features, but why force everyone to pay the power user tax? I accept that Microsoft probably don't want to invest heavily in their Oracle provider. That's fair enough: it does what the non-power-users need, and power users can go to third parties. What bugs me is the deprecation: the fact that if I now use OracleClient, I'm going to get compiler errors (yes, we compile with warnings as errrors, and that includes ObsoleteAttribute warnings). We are not being told, "Don't expect great things from this provider, because it's fairly basic." We are being told, "Don't even use this provider: use something else instead."Anonymous
June 16, 2009
Take a look at ATTUNITY - http://www.attunity.com/oracle_cdc_for_ssis Life will move on.Anonymous
June 16, 2009
Jak możecie dokładniej przeczytać na blogu teamu ADO.Net szukuje się istotna zmiana w tym komponencieAnonymous
June 16, 2009
i used ODP.Net because i need Userdefined types and arrays in our oracle stored proc.and i am surprised to see the strange behaviour of ODP.Net. the code works for some time and then throws an error that is generated from the dll and after few min code work again. i have no control on that. I am bit frustrated and a bit angry that there is no information on the net. so i guess this experience with ODP.net and this disappointing news will end my playing with oracle.Anonymous
June 17, 2009
This is terrible news. ODP.NET is great to get optimal performance when required or to handle very specific Oracle stuff. It's integration in Visual Studio however is messy, it's release times differ between x86 and x64 clients as well as between Visual Studio and Framework versions, and its a disaster to debug. For quick & simple development, and to get most out of the .Net Framework, the overall availibility of a default Microsoft driver is a must!Anonymous
June 17, 2009
Surely MS will just migrate the code out into a separate assembly (assuming it's not already in one) and then open source it so it can live on. The MVC framework is migrating into the framework... And the OracleClient stuff would be migrating out. No biggie... You'll just have to ship that dll yourself in the future... Right?Anonymous
June 17, 2009
I've been using the Oracle ODP .Net version for all development for some years so the impact for me isn't too bad. The problem with Oracle is that you have to install the kitchen sink to connect to a database (ODP or not). I think if they finally decided to simplify this people might be a little happier.Anonymous
June 17, 2009
The comment has been removedAnonymous
June 17, 2009
All these years we have been telling our customers to use System.Data.OracleClient and now it is going to be marked deprecated? How do we trust Microsoft with all these yo-yo ing?Anonymous
June 18, 2009
This is REALY BAAAAD news. If you don't want to support OracleClient perhaps you should open source it and place it in CodePlex. For those that said that ODP.net is ok let me remember you that many times you need to use a client installation in wich you can't install anything specialy a new Oracle Client that is what is needed if you need to use ODP.net and is not installed. And ... WHY DEPRECATED ??? If you're not going to develop anything else there , ok, but "deprecated" means that now I get warnings that I don't need and, by the way, if you said something is deprecated is usualy because something else is replacing it and this is not the case here.Anonymous
June 18, 2009
It is very sad. My experienece is that OracleClient is much more superior then Oracle provided ODP.net. Oracle can't create good client for their own product :-)Anonymous
June 18, 2009
This is a great disappointment. We have attempted to use ODP.net twice and have always had to come running back to the Microsoft provider due to stability issues with Oracle's solution. Having a reliable solution for connecting to Oracle within the .Net Framework is a fundamental necessity for many of us. This is especially true now that Oracle is poised to own Java. Where will Oracle be concentrating their efforts? We love the stability of the Microsoft Provider. Please reconsider. If nothing else, putting the code up on CodePlex would be both a great idea and well received service to the community.Anonymous
June 18, 2009
Hi Everyone, I hope you can give ODP.NET a second look if you can. Many improvements have been made over the years. Here is the download link: http://www.oracle.com/technology/software/tech/windows/odpnet/index.html Here's just a few things you might not know about:
- XCOPY deployment. You no longer need to use the Oracle Installer to install. We give you files and you just need to gac a few DLLs and update the registry. To download this version look for the "ODAC with Xcopy" download in the list.
- You can use any version of ODP.NET (latest is 11.1.0.6.21) against any version of the database back to 9.2.
- Multiple versions of ODP.NET can live on the same machine.. so if you choose to standardize against one version for one app and against another version for another app, that is ok.
- There have been lots of new features for for ODP.NET as well as the Visual Studio tools... too many to list here...here are the product pages for more details, videos, code samples, whitepapers, etc. ODP.NET: http://www.oracle.com/technology/tech/windows/odpnet/index.html Oracle Developer Tools for Visual Studio http://www.oracle.com/technology/tech/dotnet/tools/index.html Oracle Providers for ASP.NET http://www.oracle.com/technology/tech/dotnet/aspnet/index.html Christian Shay
Anonymous
June 18, 2009
imho, another MS move trying to drive shops that use .NET towards monolithic tech stack solution (MSSQL and the rest...).Anonymous
June 18, 2009
Say Good Bye to consistent quality. And easy deployment, one might add. Now, go and refactor, re-write and re-test your applications and try to figure out whether your solution works with all the different versions, patch sets and critical patch updates. BTW, what's the ODP.NET versioning scheme of the day? And are those tools out of Beta yet and ready for VS 2008 or later? What does the price tag on support read? Does Standard suffice or would it better be Enterprise? We had a big discussion back in the days about the db clients we'd support and it was a tough choice. We were wrong, it goes to show. Now, what other System.* namespaces can we expect to vanish over time?Anonymous
June 18, 2009
While I'm at it... What does that mean for the ORACLE Data Provider in SQL Server Reporting Services? Do we need to update all reports?Anonymous
June 18, 2009
It's about time. Oracle's ODP.NET (which does not cost anything extra) works well and has many necessary features that are missing in Microsoft's provider. For those complaining about deployment, don't forget that Microsoft's System.Data.OracleClient still requires that you install the Oracle Client on the machine, and it's usually the Oracle Client installation that trips up those unfamiliar with Oracle.Anonymous
June 18, 2009
Really bad news! We are ALWAYS using the MS .net oracle provider in all our commercial products for the following reasons:
- it's included in the .net framework (easy install)
- it offers all the functions we need
- it's also available with Mono As far as i know from my last research, ODP.Net IS NOT available in Mono - this is a big problem for us cause we want to port our .net server code to mono to be able to run also on linux boxes. @Christian Shay: What is the current status with ODP.Net and Mono ?
Anonymous
June 20, 2009
The comment has been removedAnonymous
June 21, 2009
Microsoft abbandona OracleClientAnonymous
June 21, 2009
I have had both the MS providers and Odp.net working in the Enterpise Library. We switched to Odp to work round a problem with Clobs in the MS provider but now we have a memory leak on connections; plus ca change I supposeAnonymous
June 22, 2009
Come si legge qui . "After carefully considering all the options and talking to our customers, partnersAnonymous
June 22, 2009
No words... a terrible decision. .NET MUST have a native support for Oracle and OracleClient IS a great product. Please not to go on this direction...Anonymous
June 22, 2009
Bye Bye System.Data.OracleClientAnonymous
June 22, 2009
The comment has been removedAnonymous
June 22, 2009
you guys are silly-- move to SQL Server-- it is a better database, it is extremely powerful and cheaper. anyone that uses oracle today hasnt done their homework. SQL Server wins every competition between the twoAnonymous
June 22, 2009
About a week ago Microsoft announced that the System.Data.OracleClient namespace will be deprecated inAnonymous
June 22, 2009
Pick of the Week: Resisting Dependency Injection General How PLINQ Processes an IEnumerable<T> on Multiple Cores : Igor Ostrovsky walks us through the different possible implementations of processing an enumerable collection across multiple cores.Anonymous
June 22, 2009
The comment has been removedAnonymous
June 22, 2009
...and of course you wants us to believe that this has NOTHING to do with Oracle´s purchase of Sun Microsystems, the main competitor to .Net with Java? I think that Microsoft has just decided to punish Oracle, and its customers too. After all, what else would Microsoft want but to tell people "see, using Oracle database means trouble, why not migrate everything to .Net and SQL Server and be happy?". Where is the antitrust investigation when one needs it?Anonymous
June 23, 2009
Connect for ADO.NET from DataDirect Technologies offers a client-less solution for .NET platforms –free from OracleClient or so called Instant Client . Go grab a copy of our install to check out what a true pedigree, 100% managed provider can offer while supporting the latest .NET technologies such as the ADO.NET Entity Framework provider for OracleAnonymous
June 23, 2009
Download URL for Connect for ADO.NET - Oracle http://www.datadirect.com/downloads/main-registration-form/verify/index.ssp?&atc=DDWBDNLDCADONETAnonymous
June 24, 2009
@Angel Ochoa I totally agree. If the installation consists of things like "install.bat", everything will be fine. BTW, is that then also "uninstall.bat", "repair.bat" and "patch.bat"? (Wait, wasn't that "opatch.bat?")Anonymous
June 24, 2009
The comment has been removedAnonymous
June 29, 2009
@# Jonathan Bruce: way too expensive, i really don't understand why you have customers at all when there are free options there. removing the need for the oracle client can't justify your price - but you have customers so i guess everybody is happy :)Anonymous
July 01, 2009
@Henry Boehlert The bat file is just a guideline, if you look into it you will realize that it's rather simple to setup, you can deploy it yourself with little to no pain. And BTW , yes, there is an uninstall.bat and the install can be used to repair.Anonymous
July 08, 2009
Just another reason to go back to Java. EF is nothing but marketing rubbish, using it is painful after the first day. .NET has always had a problem with DB vendor drivers, now it's going to get worse.Anonymous
July 09, 2009
Oracle has created a special website for OracleClient developers who are interested in learning about how and why to migrate to the Oracle Data Provider for .NET.. check it out: http://www.oracle.com/technology/tech/dotnet/msoc/index.html I also did a blog entry on this subject: http://cshay.blogspot.com/2009/07/microsoft-deprecates-oracleclient-time.html Christian ShayAnonymous
July 09, 2009
The comment has been removedAnonymous
July 09, 2009
The comment has been removedAnonymous
July 13, 2009
We can not move from Oracle to MS SQL. So we have to move from .Net to Java. It's hard to understand. MS again punish loyal developers.Anonymous
July 13, 2009
The comment has been removedAnonymous
July 14, 2009
This is bad news. It might save MS some money, but it will cost us and our customers a lot of time and money. Please reconsider.Anonymous
July 15, 2009
Will the .NET Framework 3.5 work with 11g Oracle Client? We have plans to migrate to 11g and are unable to determine if 11g will be compatible.Anonymous
July 15, 2009
The comment has been removedAnonymous
July 16, 2009
The comment has been removedAnonymous
July 17, 2009
SQL server is much more better than this. Symtex are an expert database consultancy and development provider. We live, breath and eat Microsoft SQL Server and .Net programming day and night; really we love it and it's that passion which keeps us at the top.Anonymous
July 27, 2009
I have been using ODP.NET since my first integration of .net to oracle many years ago. It is free and stable and is created by the provider for .net. Come on complainers, it works great, you can not expect MS to develop client tools for every database out there. I think those tools should be provided by the database entity, they are the experts of there own database btw. I use oracle for .net, db2s client for .net. Oracle also has a great support for their tools.Anonymous
July 27, 2009
I am not sure why people are whining so much about this. Have they looked at the fact sheets? The technical information link has been provided in the previous posts many time.
- ODP.Net is free.
- ODP.Net is fully supported by Oracle, and Oracle claims it will be free forever.
- Oracle claims it has a larger developer community then Microsoft OracleClient. This is important for your problem solving.
- ODP.Net is more integrated into Oracle databases and out-performces Microsoft OracleClient in many development areas.
- ODP.Net is way more up-to-date than OracleClient in terms of patches and fixes for all versions of Oracle databases.
- OracleClient will continue to work in the next 8 years. I don't know how those people claimed they trusted and used Microsoft OracleClient would explain if their vendors/clients asked them "Why haven't you used ODP.Net to develop our applications and boost the performance?" Would they just say, "Oh, we trust Microsoft and OracleClient is free!" Or "We only know OracleClient". Anyway, you have the next eight years. If you stop whining now, I am sure there will be enough time to migrate your technical skills to a better tool.
- Anonymous
July 27, 2009
@Alvonics: I don't know why are you bit#$ Slaping at everyone. If thats the way you deal with developers as a boss I would have fired you immediately.
I don't care about ado.net providers since I don't use EF, NHibernate, Linq, etc. I just plain old PL/SQL. And just use the provider as the data channel, by using Enterprise Library 4.1 or the DataProviderFactory. I would not use DataDirect because of the conversion from standar query to bound variables it does with Oracle, at the Guatemala Social Security Institute we had to deprecate the use of it, since it impacted on data type mismatches and forced full table row scans. ODP.NET It's a good one, but as usually oracles always take to long to build de 64Bit version and only deliver beta releases for a long time, the 32Bit versions can't be used on 64Bit OS's so you have to stay with the last released 64Bit or use 32Bit OS's. That's the only thing that has happened in the past, but It works verywell.
Anonymous
July 27, 2009
This decision is a good reason not to use .NET 4.0. I don't want to waste time in ODP when I can simply use OracleClient, which works perfectly indeed. Simplicity is beautiful... This is a really bad choice. Did Oracle push Microsoft to deprecate OracleClient ?Anonymous
July 27, 2009
The comment has been removedAnonymous
July 27, 2009
@ Jonathan Bruce I have looked at DataDirect in the past, but as each of our customers will have to buy it, it is not an option. If it was affordable for a ISV the price would be on your website. As it is necessary to ask the price, it is clear we can not afford it!Anonymous
July 27, 2009
Hi Christian Shay As to ODP.NET now being better…. What if the customer has another application on the same machine that has installed an older version of ODP.NET? XCOPY != just need to gac a few DLLs and update the registry !!!!!!! XCOPY == compiler my app, copy it and all the dlls from the bin directory (to the customers PC), edit the database connect string, run (and nothing else) (Having to install ANY oracle software on a PC so it can talk to a Oracle sever is not good enough.)Anonymous
July 27, 2009
The comment has been removedAnonymous
July 27, 2009
This is a terrible decision in my opinion. Connectivity with a hugely popular database is critical. 3rd party support is simply not good enough. You can't include paid for alternatives in your analysis as you are effectively replacing something that was free with something that costs. You claim that "many of the third party providers are able to consistently provide the same level of quality and support". In your recommendations and guidance you need to be able to suggest a suitable alternative that provides the same level of quality and support at the same cost (free). If you can't do that then your statement is totally worthless. Perhaps you should stop supporting internet explorer too because there are equally good third party alternatives.Anonymous
July 28, 2009
This is bad! Most of our applications are using the system.data.OracleClient! If I knew Microsoft was going to do this I would not have used it to begin with. Now we have a bunch of rework and have to pay extra $$$ for a 3rd party provider???Anonymous
July 28, 2009
Might as well just rewrite this #@%$@ in J2EE now ;(Anonymous
July 28, 2009
I checked my calendar to make sure, that it is not April fools day. This can not be serious. We have large Oracle applications that we want to use for the next years, meaning with .NET frameworks after 4.0. And now we are told, to invest (huge) amounts of time and money to replace the good and stable OracleClient provider with some other, usually less stable provider? And for what? Only to have the same functionality in the app that we have today? You do not have to be accountant to find and that this does not pay off. For ISV that write database applications it's like saying we will deprecate the command buttons and the grid in WinForms, because there are third party vendors that provide controls with the same functionality. This decision should be reconsidered.Anonymous
July 28, 2009
see also http://stackoverflow.com/questions/1193066/how-to-write-a-net-application-that-works-with-both-sqlserver-and-oracleAnonymous
July 30, 2009
Hi Ian, One way to easily ensure that the required Oracle client side software (including ODP.NET) is always available on the deployment machine is to embed it with your application. ODP.NET has gotten a lot easier to embed now that XCOPY ODP.NET is available. You can download it from this link: http://www.oracle.com/technology/software/tech/windows/odpnet/index.html With XCOPY ODP.NET, all you need to do when you deploy your application is the following:
- Copy your application to the target machine
- Run "install.bat" which copies a couple of Oracle DLL's to the target machine (including ODP.NET and the Oracle client side (OCI) software)
- Run "configure.bat", which does a "gacutil" and updates the registry of the target machine
- Provide your application with connect string information. You can use the EZCONNECT connect string ("hostname@servicename") or you (or your customer) can share preexisting sqlnet configurations by setting the TNS_ADMIN registry entry or environment variable to point to another Oracle home that has sqlnet connect aliases already configured. That's it! It is really that simple. I hope you will take a good look at ODP.NET XCOPY in the link above to see for yourself how easy it is these days to embed ODP.NET with your app. Additional notes: If you choose not to embed ODP.NET with your application, in both the case of Microsoft OracleClient and in the case of ODP.NET, there needs to be additional Oracle client side (OCI) software installed on any deployment machine. The only difference between the two cases is that when you are using ODP.NET, it also needs to exist on the deployment machine. The good news is that a typical Oracle install on your customer machine will include ODP.NET already. Now, if your target machine already has ODP.NET installed you don't need to do anything else. You just need to distribute your application. If you do need to install ODP.NET using the standard installer, you can also download it from the link provided above. The standard ODP.NET install only takes a few minutes and configures everything for you. And again, you can use EZConnect connect strings to make networking configuration a piece of cake, or use the TNS_ADMIN registry entry or environment variable to take advantage of pre-existing connect aliases that your customer is already used to using. Hope this helps, Christian Shay Oracle http://cshay.blogspot.com/
Anonymous
July 30, 2009
The comment has been removedAnonymous
August 04, 2009
Yet another reason why I like the backwards compatibility of the Java platform.Anonymous
August 04, 2009
really its very-2 disappointing. I have use ODP.net really verry pain full due to version problem there are lots of dependency. it takes 2-3 days to fix a issue.Anonymous
August 06, 2009
The comment has been removedAnonymous
August 11, 2009
Decisions like this are made all the time because financial matters rule a free market economy; not science, engineering, or even common sense if you consider the factors that contributed to the current economic conditions. While some may not like decisions like this, myself included since my company uses Oracle database technology and the Microsoft data provider, it is a common reality that computer scientists, software engineers, software developers, and the like, should take to heart and seriously rationalize how systems are built and maintained in light of these conditions. Too few of us think about these conditions and simply jump at the easiest to implement and lowest cost. No matter which way you bend, Microsoft or Oracle, .NET or Java, proprietary or open-source, there is no guarantee you will not face one of these situations at one time or another. Take it as a learning experience and don't get caught with your pants down again.Anonymous
August 12, 2009
Microsoft opportunity: put OracleClient as open source, publish it at CodePlex, I guess there is an enthusiast community ready to support it.Anonymous
August 15, 2009
I would like to ask you to refrain from telling people that you have done this in the interest of users. I am telling you that this did NOT help me. So, just be honest and admit that you are orphaning yet another product.Anonymous
August 26, 2009
What?? We just started QA and now this? It's the only driver that could do what we wanted. the oracle capable ODP version is still in Beta. Security tools such as papaSec simply block ODP and some arhitects demamnd nothing but Microsoft very own." No third party" Any chance Microsoft could buy Oracle in the near future?Anonymous
August 26, 2009
I wanted to clarify something... the 11g Oracle Client (and ODP) will run against various database versions (back to 9.2?). The problem is that if you compile your application against the 11g version of the ODP library, then you must have 11g client installed wherever you deploy your software. With MS OracleClient, this was never a problem. The MS library would work regardless of which Oracle client you had installed. Does anyone know how to bind to a ODP generically? That is, without specifying the version?Anonymous
September 07, 2009
Now you can migrate your application from OracleClient to Devart dotConnect for Oracle in two single steps. For more information please refer to this article http://www.devart.com/blogs/dotconnect/?p=67Anonymous
September 14, 2009
You should really look at DataDirect for independent database access. We compared them to Oracle's provider and found A LOT of reasons to embed their products. Their performance and support were the top reasons. They have been in business with ODBC, JDBC, and ADO.NET technology for 15+ years so they are doing something right. We were concerned with cost as well, but after just talking to their sales reps, we came up with an agreement that really is cost effective for us. We're not a big ISV either!!! I'm really glad we made this decision since I do have flexibility to switch databases if needed with their ADO.NET technology. What I like more than anything is that I'm NOT locked into Oracle or MS at all.Anonymous
September 16, 2009
Hi Will Smith, Yes ODP.NET 11g will work with databases back to Oracle 9. Please see my comment to Ian up above about how to use the XCOPY version of ODP.NET. I think it may solve your concerns about having the right client software available on the machine you target. Xcopy download (new production version just released!): http://www.oracle.com/technology/software/tech/windows/odpnet/index.html Special Oracle web site for OracleClient users: http://www.oracle.com/technology/tech/dotnet/msoc/index.html Christian Shay OracleAnonymous
October 01, 2009
I am not sure this all together good. We are an Oracle shop, but we have had major problems with ODP.NET. We are revisiting the decision and looking to use System.data.Oracle.NET. ODP.NET worked ok with client/server applications , but with 24x7 services it was totally unreliable. In one area we found Oracle was not designed to allow connection pooling they seemed to bolt something on to support .NET to support stateless applications, we never really got it to work with 9.2 . Typically we got issues around data base connections, we got all sorts of problems with memory leaks , orphaned connections and transactions that could not be closed other than by killing the applications. Even in client server appllications it brought the machine to its knees, to get round some issues we were forced to invoke the garbage collector and manually destory instances which all goes against the philosphy of .NET. I have to say things improved a lot with later versions but it all pointed to the fact that ODP.NET is not itself designed as manged code from the ground up. Of late we have found that we can't use 10.2 with our strongly typed datasets, ( fixed with 11g). I know people say it works with a 9 or 10g data base, but does it work with 9i client, 10 g client or have we got to have 3 versions of the SQLNET clients with the associated homes to manage. This is not a nice prospect when we are looking at Smart client deployment. We also found ODP.NET at time was behind the development curve, so a new version of .NET framework we had to wait for Oracle to catch up. Smart client is another area where Oracle don't make it easy, it would be better to get Oracle clients installed and managed the same as MSSQL clients. What worries us most is the lack of support of Oracle on various Windows operating systems. So my understnading is 11g is limited to a few windows operating systems. It is a shame because ODP is richer (in parts) better support for various .NET features. I would love to fix on one version, but cons of ODP.NET make it a difficult decision. You can live and work around less functionality but not you can't work round the support issues.Anonymous
October 19, 2009
ah, gotta love microsoft for not knowing when they have a good thing going. they did it to vb(6), classic asp, .net 1.x, datasets /asmx web services, now oracle client. (if i had a dollar for every time i had to rewrite the same stupid app! -- i'd have used php) if they're gonna be that way, i guess i'll just keep compiling as framework 2.0 and leave it at that. until the whole .net framework is depreciated, that is. heck, even windows xp is "depreciated" and only available to businesses as a downgrade license, as a way to force people to buy vista, which nobody wants.Anonymous
November 18, 2009
This is a great disappointment. Much year developing with Microsoft class to max compatibility and now i need to buy another library to use Oracle db? I need to revamping all my procedures and buy another software? I think this is a very wrong way for Microsoft and they pay this wrong idea, developer is the heart of Visual Studio, keep in mind. I think if this is the interess of Microsoft for developer world , then, is very very low. sry for my english , i am italian.Anonymous
November 18, 2009
We offer dotConnect for Oracle Express, which is a free fully managed ADO.NET provider for Oracle and is fully compatible with System.Data.OracleClient both by interface and behaviour.Anonymous
December 10, 2009
That is indeed disappointing, we also the Oracle layer from Microsoft. We were using the Oracle one in the past but is suffer from many memory issue. All the performance test as always put the micrisift layer faster then the Oracle one Clearly not a good new for us FredAnonymous
December 17, 2009
Actually this is fantastic news! The less we have to rely on draconian namespaces from MS, the better. The Oracle DAC is much better anyway and faster from what I can see so far. Good move in my viewAnonymous
December 26, 2009
Hi Himanshu, what about giving the community access to the System.Data.OracleClient source code to support bug fix and evolutions?Anonymous
December 29, 2009
- What about using Mono's System.Data.OracleClient on Windows?
- I don't like any feature removal. Many our applications use System.Data.OracleClient simply because it's built-in and it works. On the other hand I understand the removal, because System.Data.OracleClient is something really strange. I guess it's written in C++/CLI with portions of native code. It relays on Oracle DLLs - so I does not work when you install only .NET Framework - the provider is not .NET-native. I was really surprised when I ran Reflector on System.Data.OracleClient for the first time to see something like in in core Framework. I don't say that any other provider is better (in fact I doubt it). AFAIK there can't be no .NET-Native provider for Oracle (like MySQL has) because oracle comunication protocol is not open and one must pay horrible license fees to Oracle to get specification.
- It'd be really interesting to have source or System.Data.OracleClient on CodePlex. I'm really very interested how it's written!
Anonymous
January 06, 2010
The comment has been removedAnonymous
January 29, 2010
I'm using MS application blocks in our application. If I want to use ODP.Net, Can I use both in the same application wihtout tweaking any code in the MS Data Access application block? Since I'm using Logging application block I can not exclude MS Data access block from teh applciation. Please advise.Anonymous
February 12, 2010
Stupid, stupid decision Microsoft. I can't thnk of any good words to put here because I'm so shocked you would make such a fundamental decision without feedback from your REAL CUSTOMERS!Anonymous
February 22, 2010
The comment has been removedAnonymous
March 02, 2010
The post on 2/22/2010 above describe two major challenges facing developers who want to switch off of the Microsoft OracleClient provider and use the ODP.NET provider: • The unmanaged ODP. NET provider requires the download, installation, configuration, and maintenance of the Oracle client libraries on every machine the provider is deployed onto. • The ODP.NET provider does not support ADO.NET Entity Framework and by extension, LINQ to Entities. The Connect for ADO.NET provider from Progress DataDirect addresses these limitations today: • The Progress DataDirect ADO.NET provider for Oracle is 100% managed. 100% managed means faster, simpler, more reliable, and zero need for the Oracle client, pure and simple. And, unlike competing providers that claim to be 100% managed but require the Oracle client to support key features, the Progress DataDirect provider supports all of its features without requiring the Oracle client at all. • The Progress DataDirect ADO.NET provider for Oracle supports the Entity Framework and LINQ to Entities. This means you can start coding Entity Framework applications that need to access Oracle today. And, because the Progress DataDirect provider is 100% managed, you can be assured that your applications will always outperform any other Entity Framework solution to Oracle both now and into the future. Trying the Progress DataDirect provider is quick and painless, so start coding .NET applications to Oracle today without limitations and get ahead. http://www.datadirect.com/products/net/net_for_oracle/index.ssp Mike Frost Progress DataDirectAnonymous
March 16, 2010
Have to admit, as an Application Architect, heavily certified in MS, I am seriously considering talking to my customers about using J2EE. Such a pity given how good .Net Framework 4 was looking! Still, at least one customer may not need to renew their Enterprise Agreement.Anonymous
June 04, 2010
Been really happy with the Microsoft provider for years. ODP has been nothing but trouble. I don't understand the move.Anonymous
June 10, 2010
Please do not continue reducing the functionality of .NET. Third party api/library vendors add considerable long term support cost and risk to our production applications given that they have a 5 to 8 year production lifespan. Please profide a basic way to connect to, issue queries and do basic transactions against Oracle databases. We do not need schema browsing or any higher level features. Basic plumbing such as connectors to widely used mainstream database servers should be a must have feature in .NET. Removing Oracle support heads .NET in the same direction as removing any non-Microsoft computer to computer connection protocols (e.g., only suppurting DCOM and not tcp/ip).Anonymous
August 02, 2010
The comment has been removedAnonymous
October 06, 2010
Is there an update for Microsoft's oracle client wich adds support for Oracle Client 11g?Anonymous
October 21, 2010
Best Software Downloads and Reviews. the most comprehensive source for free-to-trysoftware downloads on the Web<a href="www.best4downloads.com/">BEST 4 DOWNLOADS </a>Anonymous
March 10, 2011
Well moving to a third party may be OK for some - but for others the adoption of third party drivers involves a lot of procedural processes which will adversely affect time lines. When you have thousands of computers in your organization and hundreds of existing apps it takes an enormous effort to avoid unintended consequences.Anonymous
March 21, 2011
The least Microsoft could do in the interim is to persuade Oracle to write a standard data provider. For example on in which the OracleException is derived from DbException.Anonymous
March 23, 2011
In fact nothing derives from the "Db" types. Everything uses the "IDb" interface. This should create some interesting program breaks.Anonymous
May 01, 2012
How to connect vs2010 to cloud oracle 11g database, i can try to connect but i can getting an error error is "servicename"Anonymous
February 22, 2013
Himanshu Vasishth Kellerman Software has an Oracle LINQ provider www.kellermansoftware.com/p-47-net-data-access-layer.aspxAnonymous
March 20, 2014
Oracle is pushing its way harder in cloud software. It had growth of 24% from revenues in cloud and 60% growth in bookings. It will take time for transition from traditional licensing based software to cloud based software offerings, but company will catch up with its competitors. posted by: http://bit.ly/1geCfP7Anonymous
May 14, 2014
Hi, I have an Application built on .Net framework 3.5. I am using System.Data.OracleClient to connect to the database. I have both Oracle 10g and Oracle 11g client installed in my machine. How do I find out the client that is being referred to by the System.Data.OracleClient dll? Thanks