ODP.NET, Managed Driver: what the coming day prepares for us

Hello, dear Habrovchane. Today I want to tell a little about ODP.NET, Managed Driver. Now on the Oracle website version Beta 11.2.0.3.60 is available, which shows us what ODP.NET will become in the near (I hope) future.

So, what is remarkable about ODP.NET, Managed Driver:

• 100% managed provider
  As Oracle constantly emphasizes in various sources, ODP.NET, Managed Driver is a fully managed provider, unlike the classic ODP.NET.
• One library ~ 6 megabytes in size instead of a heap of libraries for ~ 150 megabytes
  To use the provider, it is enough to add one small library Oracle.ManagedDataAccess.dll to the project.
  
• Does not use Oracle client files
  For the Managed Driver to work, you do not need to install an Oracle client. One tablet library is enough.
• One build for 32-bit and 64-bit systems
  No need to use different build providers for 32-bit and 64-bit systems.
• Installation using OUI and xcopy
  You can install it using the installer or simply unpack the archive and execute one script.
• Supports Oracle 10.2 and higher
  The latest three versions are supported.
• Certified for Net Framework 4 and above and Visual Studio 2010 and 2012

Spoons of tar

At the moment, not all the functionality of the old ODP.NET, Unmanaged Driver is supported by the Managed Driver (For details, see the plate Differences between odp.net, managed driver and odp.net, unmanaged driver). However, the developers promise to fix this release.
')
Also, not everything goes smoothly with the support of distributed transactions. First, Microsoft Distributed Transaction Coordinator API calls are uncontrollable (it is claimed that Oracle with Microsoft goes to 100% of controllability), secondly, Oracle Services for MTS works only with unmanaged ODAC version (proposed to be installed in a separate Oracle Home), Thirdly, the provider has to pull up the additional library Oracle.ManagedDataAccessDTC.dll (two versions: 32-bit and 64-bit)

Migration to ODP.NET, Managed Drive

So, now a little about the transition from Unmanaged Driver to Managed. It is argued that for successful migration, it is enough to add a new library to References, replace the namespace and you can reassemble the project. Check it out.

Take the Hello Word application for ODP.NET, Unmanaged Drive:

using System; using System.Collections.Generic; using System.Linq; using System.Text; using Oracle.DataAccess.Client; using Oracle.DataAccess.Types; namespace ConsoleUnmanagedTest { class Program { static void Main(string[] args) { string constr = "user id=scott;password=tiger;data source=orcl"; OracleConnection con = new OracleConnection(); con.ConnectionString = constr; con.Open(); Console.WriteLine("Connected to: " + con.DatabaseName); using (OracleCommand cmd = con.CreateCommand()) { cmd.CommandText = "select ename from scott.EMP where deptno = 30"; using (OracleDataReader reader = cmd.ExecuteReader()) { while (reader.Read()) { Console.WriteLine("Name: " + reader.GetString(0)); } } } con.Close(); con.Dispose(); Console.ReadLine(); } } } 

Make sure it works.

Then we download the ODP.NET distribution kit, the Managed Driver from the Oracle website (I chose Xcopy, unpacked it on my computer, and ran the configure.bat script). In the project's References, delete the “old” provider and add Oracle.ManagedDataAccess.dll. After this, we replace in our code the namespaces:

 //using Oracle.DataAccess.Client; //using Oracle.DataAccess.Types; using Oracle.ManagedDataAccess.Client; using Oracle.ManagedDataAccess.Types; 

Run ... and get the error "ORA-12545: Network Transport: Unable to resolve connect hostname". Yes, it's time to remember that thanks to ODP.NET, the Managed Driver, our application is no longer tied to the Oracle client installed on the machine, so it does not know about tnsnames.ora in Oracle Home.

To solve the connection problem, simply put the tnsnames.ora file in the folder with the exe file. The resulting exe file, the Oracle.ManagedDataAccess.dll library and the tnsnames.ora file can be run on a computer without an Oracle Client to make sure that the application works fine there.

Using the Application Configuration File you can set TNS Names more flexibly:

• Set directory path with tnsnames.ora

 <?xml version="1.0" encoding="utf-8" ?> <configuration> <oracle.manageddataaccess.client> <version number ="4.112.3.60"> <settings> <setting name="TNS_ADMIN" value="D:\OracleTestNetwork\"/> </settings> </version> </oracle.manageddataaccess.client> </configuration> 

• Register alias:

 <?xml version="1.0" encoding="utf-8" ?> <configuration> <oracle.manageddataaccess.client> <version number ="4.112.3.60"> <dataSources> <dataSource alias="orcl" descriptor ="(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.1)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = orcl)))"/> </dataSources> </version> </oracle.manageddataaccess.client> </configuration> 

Conclusion

Undoubtedly, the new provider ODP.NET, Managed Driver looks promising. Manageability will allow you to effectively control resources, and small size, independence from the Oracle client and OS capacity will simplify the development of applications and their deployment to end users. It remains only to be patient and wish good luck to Oracle.