doc.Whitepaper.udadnet

As a core element in the ADO.NET architecture, your choice of data provider is crucial. The aim of this White Paper is to describe OpenLink? .NET providers and highlight key considerations you should bear in mind when selecting a data provider.

• Contents: *

• ADO.NET - The New Data Access Paradigm
  
• OpenLink? UDA NET Providers
  
• Managed Generic Provider
  
• Unmanaged ODBC Bridge Provider
  
• Key Features
  
• OpenLink? Provider Architectures
  
• Selecting an NET Provider
  
• Zero-Install Deployment
  
• Cross-Platform .NET
  
• Cross-Database Uniformity
  
• Database-Independent Class Names
  
• Error Handling
  
• Parameter Binding
  
• Standard SQL Grammar
  
• Managed vs Unmanaged ADO.Net Providers
  
• Benefits of OpenLink? .NET ODBC Bridge Provider
  
• Generic (Multi-Tier) client
  
• TDS wire-protocol providers for connectivity to Sybase and Microsoft SQL Server
  
• Connection pooling
  
• CommandBuilder? ? support
  
• Unicode support
  
• Transparent Unicode / ASCII text conversion for non-Unicode database / table / column instances
  
• OS independence - Support for Microsoft and Mono CLRs.
  
• 100% managed client for optimum performance, security and deployment flexibility
  
• Cross DBMS uniformity
  
• Uniform, database-independent, SQL syntax for scalar functions and stored procedure calls
  
• Native SQL supported via pass-through
  
• Uniform, database-independent, parameter binding
  
• Uniform, database-independent, data type handling
  
• Uniform, database-independent, error handling and reporting
  
• Single database-independent namespace enhances code portability
  
• Broad database coverage, including
  
• Oracle, DB2, Informix, Sybase, SQL Server, Progress, Ingres, MySQL? ?, PostgreSQL? ?
  
• 100% managed TDS wire protocol driver for connecting to Sybase or Microsoft SQL Server
  
• Exceptional performance
  
• Wire-protocol architecture bypasses the database''s native API.
  
• Provider communicates directly with the database through its wire level protocol.
  
• No server-side OpenLink? components required
  
• Provides access, from both Windows and Unix variants supporting Mono, to databases not supported by the OpenLink? Generic Managed Provider, through third party ODBC or iODBC drivers ( OpenLink? ODBC drivers are also supported but do not necessary have to be used).
  
• Offers superior usability to the Microsoft .NET Provider for ODBC
  
• Extensive internal statement analysis provides meta-data not provided by the Microsoft .NET ODBC bridge. The additional meta-data ensures correct operation of the CommandBuilder? ?, IDataReader? ? and IDbCommand? ? interfaces.
  Universal Client (Multi-Tier) * - The OpenLink? VDB(Virtual Database) layer has been ported to C# and linked into the Provider, enabling it to communicate directly with the OpenLink? Multi-Tier Database agents installed on the remote machine (or via 3-Tier connection) as indicated in the diagram below:

[[/images/dnetmanage.jpg|]]

/ Image scaled down; Click to enlarge./

TDS Wire Protocol * - The TDS protocol has been ported to C# and linked into the Provider, enabling two 100% Managed Providers to be created capable of direct connectivity to Microsoft and Sybase SQLServer Databases without the need for any additional components on the Server, as indicated in the diagram below:

[[/images/../images/dnetmantdsms.jpg|]]

/ Image scaled down; Click to enlarge./

[[/images/../images/dnetmantdsyb.jpg|]]

/ Image scaled down; Click to enlarge./

[[/images/../images/dnetunmanage.jpg|]]

/ Image scaled down; Click to enlarge./

• Key Features *

• Network-centric license management and enforcement
  
• Sophisticated infrastructure manager based on applying a "Session Rules" Book approach
  
• Naming and resource binding service provider to all OpenLink? client components
  
• Sophisticated data marshaling and logical network message assembly
  
• Logical firewalling
  
• Key Features *

• OpenLink? ''s providers support both the Mono and Windows CLRs
  
• OpenLink? ''s 100% pure managed client supports zero-install deployment, with no dependencies on third party libraries.
  
• Database-specific Class Names
  
• Error Handling
  
• Parameter Binding
  
• Type Handling
  
  

  
  using System.Data.SqlClient; IDbConnection myConn = new SqlConnection; IDbCommand myCommand = myConn.CreateCommand( ); 
  

  
  
  
  

  
  using System.Data.Oracle; IDbConnection myConn = new OracleConnection; IDbCommand myCommand = myConn.CreateCommand( ); 
  

  
  
  
  

  
  using OpenLink.Data.GenericClient; IDbConnection myConn = new OplConnection; IDbCommand myCommand = myConn.CreateCommand( ); 
  

  
  
  
• Microsoft .NET Provider for Oracle *

using System.Data.OracleClient; OracleCommand myCommand = new OracleCommand(); myCommand.CommandText = "SELECT BOOKID, BOOKTITLE, AUTHOR, PRICE, RETAIL FROM PRODUCTS WHERE SUBJECTID = :SUBJECTIDIN"; 

• Microsoft .NET Provider for SQL Server *

using System.Data.SqlClient; SqlCommand myCommand = new SqlCommand(); myCommand.CommandText = "SELECT BOOKID, BOOKTITLE, AUTHOR, PRICE, RETAIL FROM PRODUCTS WHERE SUBJECTID = @SubjectID"; 

• OpenLink? Generic Provider *

using OpenLink.Data.GenericClient; OpllCommand myCommand = new OplCommand(); myCommand.CommandText = "SELECT BOOKID, BOOKTITLE, AUTHOR, PRICE, RETAIL FROM PRODUCTS WHERE SUBJECTID = ?"; 

• Key Features *

• OpenLink? providers simplify targeting of databases from different vendors by offering:
  
• a single namespace across all supported databases
  
• uniform, database independent, error handling, type handling and parameter binding
  
• a common, database independent, SQL escape syntax for stored procedures, scalar functions and outer-joins
  
• Key Features *

• OpenLink? offers pure managed providers for maximum security, performance and deployment flexibility.
  
• OpenLink? offers an unmanaged ODBC/iODBC bridge for maximum database coverage from both Windows and Unix
  
• The OpenLink? .NET ODBC Bridge offers superior usability compared to ODBC bridge providers from other vendors.
  
• cross platform support for .NET data access through ODBC and iODBC
  
• superior usability and meta-data
  
• ExecuteReader? ( CommandBehavior? ?.KeyInfo) may fail to append required key columns to the end of the select list prior to executing a query. Consequently the query result-set is not as expected.
  
• Updates through an ODBCDataAdapter? ? may fail because the Data Adapter fails to detect table primary keys.
  
• Column meta-data returned by ODBCDataReader? ?.GetSchemaTable may not include key column, baseCatalogName or baseSchemaName information.
  
• The ODBCCommandBuilder? ? may fail to generate the required DML statements because column descriptors returned by the ODBC driver do include the column''s base table name.