Microsoft SQL Server Native Client (referred to hereafter as SNAC) was introduced in SQL Server 2005 and combines an ODBC driver and OLE DB provider in a single DLL. The SQL Server ODBC driver and SQL Server OLE DB provider for earlier versions of SQL Server was delivered via Microsoft Data Access Components (MDAC), recently renamed Windows Data Access Components (WDAC) in Windows Vista and later. SNAC and WDAC coexist and serve different needs. SNAC provides support for the latest SQL Server 2005 features. If you are developing a generic application to operate with any ODBC driver or OLE DB provider (namely, an application which is not taking advantage of provider specific types), then using the Windows (WDAC) integrated SQL Server 2000 versions of the ODBC driver and OLE DB provider is a better choice since they map new SQL Server 2005 types to standard ODBC types that are compatible with SQL Server 2000 and other ODBC drivers. The differences in type behavior are discussed more in the “Differences between driver/provider versions” section below in the document.
With SQL Server 2008, we again wanted to expose new features and data types to applications in the most natural way, and we knew that some of the new features (Table-Valued Parameters, for example) would force fairly major code reorganization that would inevitably introduce behavior differences. Most applications won't be bothered at all by this, but when you take into account the huge number of applications written to use SQL Server, it's inevitable that some might be impacted. In order to minimize disruption when SQL Server is upgraded, we decided that SNAC in SQL Server 2005 (now refered to as SNAC9) and SNAC in SQL Server 2008 (now refered to as SNAC10) should be able to coexist side by side. This means that when SQL Server 2008 (or SNAC10 on a client-only system) is installed, applications already deployed using SNAC9 will see no change at all. They will simply continue to run the way they did before using the version of SNAC they originally were built with, which in this case would be SNAC9.. Switching an application to use SNAC10 requires some intervention and we strongly recommend that the application is thoroughly tested with the new version of SNAC before it is deployed in production environments.
Side by side co-existence is achieved by renaming the ODBC driver name and OLE DB progid (and allocating new classids too). The differences between SNAC9, SNAC10 and WDAC (which contains the SQL Server 2000 versions of the SQL ODBC driver and SQL OLE DB provider) are summarized in the following table:
SQL Server Native Client (SNAC9)
SQL Server 2008 Native Client (SNAC10)
ODBC Driver Name
SQL Native Client
SQL Server Native Client 10.0
ODBC Header file name
ODBC Driver DLL
ODBC lib file for BCP APIs
ODBC dll for BCP APIs
OLE DB PROGID
OLE DB Header file name
OLE DB Provider DLL
Notice that we didn't change the header file name. Since the SNAC9 and SNAC10 SDK files are installed in different paths we can avoid the need to change #include directives in source code, only the include path need be changed. To minimize future code change when SNAC11 comes along, we added macros to the header file to enable applications to automatically pick up the correct version names when they are built for a specific version of SNAC (with the default being the latest version). If you look in sqlncli.h for SNAC10 you'll see things like this:
#if !defined(SQLNCLI_VER)#define SQLNCLI_VER 1000#endif
#if SQLNCLI_VER >= 1000#define SQLNCLI_PRODUCT_NAME_FULL_VER_ANSI "Microsoft SQL Server Native Client 10.0"#define SQLNCLI_PRODUCT_NAME_FULL_ANSI "Microsoft SQL Server Native Client"#define SQLNCLI_PRODUCT_NAME_SHORT_VER_ANSI "SQL Server Native Client 10.0"#define SQLNCLI_PRODUCT_NAME_SHORT_ANSI "SQL Server Native Client"...#else // SQLNCLI_VER >= 1000#define SQLNCLI_PRODUCT_NAME_FULL_VER_ANSI "Microsoft SQL Server Native Client"#define SQLNCLI_PRODUCT_NAME_FULL_ANSI "Microsoft SQL Server Native Client"#define SQLNCLI_PRODUCT_NAME_SHORT_VER_ANSI "SQL Native Client"#define SQLNCLI_PRODUCT_NAME_SHORT_ANSI "SQL Native Client"...
Each version of SNAC will support the version of SQL Server that it ships with, two earlier versions and two later versions, so SQL Server support for the two existing SNAC versions is as follows:
SQL Server Native Client Version
Supported SQL Server Versions
Microsoft SQL Server 7.0Microsoft SQL Server 2000Microsoft SQL Server 2005Microsoft SQL Server 2008Next SQL Server version
Microsoft SQL Server 2000Microsoft SQL Server 2005Microsoft SQL Server 2008Next two SQL Server versions
The server version support structure means that there is no rush to change the driver/provider an application uses. Developers can make the changeover on a timescale that makes business sense for them, such as the next major version releases of their applications.
In a similar way, supported Windows versions may change with each SNAC version to allow for older versions of Windows dropping out of support. For SNAC9 and SNAC10, operating system support is as follows:
Supported Operating Systems
Microsoft Windows 2000 Service Pack 4 or laterMicrosoft Windows Server 2003 or laterMicrosoft Windows XP Service Pack 1 or laterMicrosoft Windows Vista Microsoft Windows 2008 Server
Microsoft Windows Server 2003 SP1 or laterMicrosoft Windows XP Service Pack 2 or laterMicrosoft Windows VistaMicrosoft Windows 2008 Server
The different driver/provider versions see SQL Server data types differently because SQL Server converts values that it sends to clients to types that are understood by the client version, as summarized in the following table:
MDAC and SQL Server Native Client OLE DB applications (SNAC9 or SNAC10) with DataTypeCompatibility=80
SQL Server Native Client(SNAC9)
SQL Server 2008 Native Client(SNAC10)
Types introduced in SQL Server 2005
CLR UDT (<= 8000)
Types introduced in SQL Server 2008
CLR UDT (> 8000)
For new types with unlimited size the maximum size is represented as SQL_SS_LENGTH_UNLIMITED (value 0) in ODBC and ~0 in OLE DB. The APIs uses different values because each API has its own convention for representing values of unlimited size (and these conventions pre-date SNAC). Applications which do arithmetic based on the size returned in parameter and result metadata and which don't take account of this special case may misbehave. This is one reason why we recommend that applications moving to new driver/provider versions should not be deployed without thorough testing. Other version differences are described in SQL Server Books Online.
Deciding which driver/provider to use with an application is straighforward once the above is understood.