= uda.dotnet.st %TOC% = Single-Tier (Lite Edition) %TOC% Single-Tier (Lite Edition) [[OpenLink]] Single-Tier ADO.NET drivers are installed on one data-consuming machine (a client, workstation or application-server, depending on architecture), providing connectivity to local or remote databases. The [[OpenLink]] Single-Tier is a client-only installation and goes some way to ensure the job for developers, administrators and end-users is simplified. There is no server-side administration so the user is provided with a single point of entry for installation and administration. In the majority of cases, knowing the database is all that is required. To the developer writing an application, there is no requirement to know on which server it resides: you can write your application for any environment, regardless of where it will end. There are also performance benefits gained by employing this single solution, which in some cases exceeds that provided by the native drivers. Being able to integrate your solution simply into your organization with its plethora of internal and disparate systems means your return on investment increases significantly. These drivers are built by implementing the ADO.NET data-access interface specifications using a database-vendor-provided Call Level Interface (CLI). Thus, the capabilities and architecture of the CLI significantly affect the functional outcome of a driver. [[/images/udadotnetst.gif|]] / Image scaled down; Click to enlarge./ ADO.Net drivers are developed using the call-level interface (CLI) of the respective databases that they support. These call-level interfaces take the following forms: *Type A - C-based dynamic SQL interface that inextricably includes client and server networking components *Type B - C-based remote procedure calls (RPC) interface to the wire-protocol of the underlying database. This is a client-only interface that communicates directly with the remote database server. These interfaces aren’t typically available to third-party developers. To date the Open Source projects such as [[FreeTDS]] , [[MySQL]] , [[PostgreSQL]] , and Interbase are the only publicly accessible and freely available versions of such interfaces. *Type C - Generic bridges: these are ADO.NET providers that act as implementation proxies, such that bridging can be achieved in the manner depicted in the matrix below: [[OpenLink]] provides Single-Tier Drivers built using the Type A, B, and C call-level interfaces formats, depending on what is publicly available to third-party developers by the vendors of the respective database engines. Please view your respective Data Access Mechanism for more information. [[OpenLink]] provides Single-Tier Drivers built using the Type A, B, and C call-level interface formats, depending on what is publicly available to third-party developers by the vendors of the respective database engines. Architectural diagrams showing the different type representations of ADO.NET drivers available. These drivers are built using the Type-A call-level interfaces of the relevant back-end database engine. Thus, these drivers implement the interfaces of the respective data access mechanisms (ADO.NET) with inherent database-specific networking, and a dependency on the database vendor provided networking middleware products. At installation time you simply install the driver with the underlying assumption that remote database connectivity is already in place (or will be put in place) via products such as Net8 and SQL*Net, Progress Client Networking, Informix Connect, Ingres Net, DB2 Connect etc. [[/images/aadonetst.gif|]] /Type A Architectural Diagram for ADO.NET Image scaled down; Click to enlarge./ [[/images/aadonetstprog.gif|]] /Type A Architectural Diagram for Progress ADO.NET Image scaled down; Click to enlarge./ These drivers are built using the Type-B client-networking interface to wire-protocols of the supported back-end database. These drivers are installed once on a workstation/desktop or application server machine, and after installation are ready for direct communication with the supported back-end database. This driver format is only currently available for; Microsoft SQL Server, SYBASE ASE, [[MySQL]] , [[PostgreSQL]] , and [[OpenLink]] Virtuoso. Support for other databases will occur as and when unsupported database engine vendors make their RPC client-interfaces available to third-party developers. [[/images/badonetst.gif|]] /Type B Architectural Diagram for ADO.NET Image scaled down; Click to enlarge./ These drivers are proxies sitting atop third-party implementations of the relevant data-access mechanisms. Their prime purpose is to integrate one data-access standard implementation with another. There are a variety of scenarios where this is useful such as: *ADO.NET access to back-end databases that are only accessible via ODBC [[/images/cadonetst.gif|]] /Type C Architectural Diagram for ADO.NET Image scaled down; Click to enlarge./ | Platform Support | Support for client, server, and application server operating systems | | 32- and 64-bit components | Enables the development and utilization of 32- or 64-Bit DBMS independent applications. | Database Engine Support | Backend database engine support | | Broad backend Database Support | Enables DBMS independent application utilization and deployment across a vast array of industry leading DBMS engines that includes; Oracle (7.x - 10.x), SQL Server (6.x - 2005), DB2 (6.x - 8.x), Sybase (10.x - 12.x), Progress (7.x - 10.x), Ingres (6.4 - II family), Informix (5.x - 9.x & IDS 2000), [[MySQL]] , and [[PostgreSQL]] . | Performance | | Blistering Performance | Delivery of data access performance levels across ODBC, JDBC, ADO.NET and OLE DB that don't compromise viability of DBMS independent application development and deployment. | Network Aware Record Retrieval | Enabling the retrieval and insertion of multiple DBMS records in batches over the network with a minimal number of network hops. | | Administration | Configuration and Management | | Single Component Installation Process | In situations where DBMS vendor networking is already in place, Single-Tier Drivers provide ease of installation and configuration since you are only required to install a single client component that inherently depends on existing DBMS specific networking for remote data access. | Standards Compliance | | International character support | Enables the development and deployment of international applications that are independent of underlying database engine. | Performance | | Multithreaded | Enables exploitation of scalability benefits arising from the use of multiple CPUs or Clusters while developing or using DBMS independent applications. | Standards Compliance | | Supports Advanced Data Access API functionality | Enables the development and utilization of DBMS application with DBMS independent granularity that extends to challenging areas such as scalar function calls, dates and timestamps manipulation, outer join handling, and SQL stored procedure invocation etc. ----