These drivers are built by implementing the ODBC 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.
Image scaled down; Click to enlarge.
ODBC (and any other data-access drivers for that matter) are developed using the call-level interface (CLI) of the respective databases that they support. These call level interfaces take the following forms:
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.
OpenLink provides ODBC-based Single-Tier Drivers for all databases, using the Type A, B, and C call-level interface formats. The type of driver provided depends on what is publicly available to third-party developers by the vendors of the respective database engines.
The ODBC Single-Tier drivers are C-based drivers and offer developers an opportunity to develop generic solutions across platforms without prior knowledge of the operating system hosting the Database server. Architectural diagrams showing the different representations of ODBC drivers based on Call Level Interface types are available below.
These drivers are proxies that sit atop third-party implementations of the relevant data-access mechanisms. The prime purpose to integrate one data access standard implementation with another, and there are a variety of scenarios where this is useful such as:
ODBC access to back-end databases that are accessible via JDBC and/or ODBC
OpenLink Single-Tier Drivers constitute a single component installed on the desktop or workstation machine only. Once installed, it provides connectivity to local or remote databases.
Our OpenLink Single-Tier is a client-only installation and goes some way to ensure the job for developers, administrators and end-users is simplified. Part of this is process means installing the software in one location as opposed to numerous locations. By discarding the server-side setup, there is no server-side administration so the user has only a single entry-point 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 ROI increases significantly.
This document is empty and basically useless. It is generated by a web service that can make some statements in HTML Microdata format. This time the service made zero such statements, sorry.