The Microsoft SQL Server ODBC driver uses the standard SQL Server components for communicating from a client application to the database server. Rather than being implemented as a new layer over SQL Server's older native API, DB-Library, the ODBC driver writes directly to the same Network-Library (Net-Library) layer used by DB-Library. The ODBC driver is implemented as a native API to SQL Server and is a functional replacement of the DB-Library DLL. The components involved in accessing a SQL Server from an ODBC application are described in the following sections.
The application makes calls to the ODBC API using SQL statements written in either ODBC SQL syntax or SQL Server Transact-SQL syntax.
The ODBC driver manager is a very thin layer that manages the communications between the application and any ODBC drivers with which the application works. The driver manager primarily loads the modules comprising the driver and then passes all ODBC requests to the driver. There are Win32® and Win16 application programming interface versions of the driver manager. The Win32 driver manager is Odbc32.dll; the Win16 driver manager is Odbc.dll.
The SQL Server ODBC driver is a single DLL that responds to all calls the application makes to the ODBC API. If the SQL statements from the application contain ANSI or ODBC SQL syntax that is not supported by SQL Server, the driver translates the statements into Transact-SQL syntax (the amount of translation is usually minimal) and then passes the statement to the server. The driver also presents all results back to the application. The Win32 SQL Server ODBC driver is Sqlsrv32.dll; the Win16 driver is Sqlsrvr.dll.
The driver communicates with the server through the SQL Server Net-Libraries using the SQL Server application-level protocol called Tabular Data Stream (TDS). The SQL Server TDS protocol is a half-duplex protocol with self-contained result sets (that contain both metadata and data) optimized for database access.
There is a different Net-Library for each protocol SQL Server supports. The job of the Net-Library is to process TDS packets from the driver while insulating the driver from details of the underlying protocol stack. A SQL Server Net-Library accesses a network protocol by calling a network API supported by the protocol stack. The Net-Libraries supplied by SQL Server for use by SQL Server client applications are listed in the following table.
| Net-Library | Win32 DLL | Win16 DLL |
| TCP/IP Windows Sockets | Dbmssocn.dll | Dbmssoc3.dll |
| Named pipes | Dbnmpntw.dll | Dbnmp3.dll |
| Multiprotocol | Dbmsrpcn.dll | Dbmsrpc3.dll |
| Novell SPX/IPX | Dbmsspxn.dll | Dbmsspx3.dll |
| Banyan Vines | Dbmsvinn.dll | Dbmsvin3.dll |
| DECNet | Dbmsdecn.dll | N/A |
| AppleTalk | Dbmsadsn.dll | N/A |
The network protocol stack transports the TDS packets between the client and the server. The protocol stack has components on both the client and the server.
The server Net-Libraries work on the server, passing TDS packets back and forth between SQL Server and its clients. Each SQL Server can work simultaneously with any of the server Net-Libraries installed on the server.
Open Data Services supports an API defined for writing server applications. An Open Data Services application can either be a server that accepts connections and processes queries (such as SQL Server or a gateway to another DBMS), or it can be an extended stored procedure that allows DLLs written to the Open Data Services API to be run as stored procedures within SQL Server. Open Data Services receives the TDS packets from the underlying Net-Libraries and then passes the information to SQL Server by calling specific Open Data Services callback functions implemented in the SQL Server code. It also encapsulates the results coming back from the server in TDS packets that the Net-Library then sends back to the client.
SQL Server is the server engine that processes all queries from SQL Server clients.
The following illustration shows the overall ODBC and SQL Server architecture. It shows both a Win16 client using TCP/IP and a Win32 client using Novell connecting to the same server.
One of the persistent rumors about ODBC is that it is inherently slower than a native DBMS API. This reasoning is based on the assumption that ODBC drivers must be implemented as an extra layer over a native DBMS API, translating the ODBC statements coming from the application into the native DBMS API functions and SQL syntax. This translation effort adds extra processing compared with having the application call directly to the native API. This assumption is true for some ODBC drivers implemented over a native DBMS API, but the Microsoft SQL Server ODBC driver is not implemented this way.
The Microsoft SQL Server ODBC driver is a functional replacement of DB-Library. The SQL Server ODBC driver works with the underlying Net-Libraries in exactly the same manner as the DB-Library DLL. The Microsoft SQL Server ODBC driver has no dependence on the DB-Library DLL, and the driver will function correctly if DB-Library is not even present on the client.
Microsoft's testing has shown that the performance of ODBC-based and DB-Library–based SQL Server applications is roughly equal.
The following illustration compares the ODBC and DB-Library implementations.
The following table shows which versions of the Microsoft SQL Server ODBC driver shipped with recent versions and service packs (SP) of Microsoft SQL Server. It also lists the operating system versions under which the drivers are certified to run and the versions of SQL Server against which they are certified to work.
Newer drivers recognize the capabilities of older databases and adjust to work with the features that exist in the older server. For example, if a user connects a version 2.65 driver to a version 4.21a server, the driver does not attempt to use ANSI or other options that did not exist in SQL Server 4.21a. Conversely, older drivers do not use the features available in newer servers.
For example, if a version 2.50 driver connects to a version 6.5 server, the driver has no code to use any new features or options introduced in the 6.5 server.
| Driver version | Driver date | Shipped with SQL Server version | SQL Server versions supported |
Operating systems supported |
| 2.65.0252 | 06/16/97 | 6.5 SP3 | 6.5 6.0 4.21a |
Windows NT3.5, 3.51, 4.0 Windows 95 Windows for Workgroups 3.11 Windows 3.1 |
| 2.65.0240 | 12/30/96 | 6.5 SP2 | 6.5 6.0 4.21a |
Windows NT3.5, 3.51, 4.0 Windows 95 Windows for Workgroups 3.11 Windows 3.1 |
| 2.65.0213 | 07/30/96 | 6.5 SP1 | 6.5 6.0 4.21a |
Windows NT3.5, 3.51, 4.0 Windows 95 Windows for Workgroups 3.11 Windows 3.1 |
| 2.65.0201 | 04/03/96 | 6.5 | 6.5 6.0 4.21a |
Windows NT3.5, 3.51, 4.0 Windows 95 Windows for Workgroups 3.11 Windows 3.1 |
| 2.50.0126 | 08/17/95 | 6.0 SP3 6.0 SP2 6.0 SP1 |
6.0 4.21a |
Windows NT3.5, 3.51 Windows 95 Windows for Workgroups 3.11 Windows 3.1 |
| 2.50.0121 | 06/07/95 | 6.0 | 6.0 4.21a |
Windows NT3.5, 3.51 Windows 95 Windows for Workgroups 3.11 Windows 3.1 |
Note: None of the Microsoft SQL Server ODBC drivers listed is certified to work with Sybase SQL Servers. Applications needing to connect to Sybase SQL Servers must get an ODBC driver certified for use with Sybase from either Sybase or a third-party ODBC driver vendor.
For more information about versions and Instcat.sql, see "Instcat.sql."