Installing SQL Server Native Client / SQL Server 2008 R2

Microsoft SQL Server Native Client 10.0 is installed when you install SQL Server 2008 R2 or the SQL Server tools. If the SQL Server 2005 version of SQL Server Native Client is also installed on the computer, SQL Server Native Client 10.0 will be installed side-by-side with the earlier version. SQL Server 2008 R2 Native Client will overwrite SQL Server 2008 Native Client.
The SQL Server Native Client files (sqlncli10.dll, sqlnclir10.rll, and s10ch_sqlncli.chm) are installed to the following location:

%SYSTEMROOT%\system32\

Note: All appropriate registry settings for the SQL Server Native Client OLE DB provider and the SQL Server Native Client ODBC driver are made as part of the installation process
The SQL Server Native Client header and library files (sqlncli.h and sqlncli10.lib) are installed in the following location:

%PROGRAMFILES%\Microsoft SQL Server\100\SDK

In addition to installing SQL Server Native Client as part of the SQL Server installation, there is also a redistributable installation program named sqlncli.msi, which can be found on the SQL Server installation disk in the following location:

%CD%\Setup\

You can distribute SQL Server Native Client through sqlncli.msi. You might have to install SQL Server Native Client when you deploy an application. One way to install multiple packages in what seems to the user to be a single installation is to use chainer and bootstrapper technology. For more information, see Authoring a Custom Bootstrapper Package for Visual Studio 2005 and Adding Custom Prerequisites.

The x64 and Itanium versions of sqlncli.msi also install the 32-bit version of SQL Server Native Client. If your application targets a platform other than the one it was developed on, you can download versions of sqlncli.msi for x64, Itanium, and x86 from the Microsoft Download Center.
When you invoke sqlncli.msi, only the client components are installed by default. The client components are are files that support running an application that was developed using SQL Server Native Client. To also install the SDK components, specify ADDLOCAL=All on the command line. For example:
msiexec /i sqlncli.msi ADDLOCAL=ALL APPGUID={0CC618CE-F36A-415E-84B4-FB1BFF6967E1}

Silent Install

If you use the /passive, /qn, /qb, or /qr option with msiexec, you must also specify IACCEPTSQLNCLILICENSETERMS=YES, to explicitly indicate that you accept the terms of the end user license. This option must be specified in all capital letters.

Uninstalling SQL Server Native Client

Because applications such as SQL Server server and the SQL Server tools depend on SQL Server Native Client, it is important not to uninstall SQL Server Native Client until all dependent applications are uninstalled. To provider users with a warning that your application depends on SQL Server Native Client, use the APPGUID install option in your MSI, as follows:

msiexec /i sqlncli.msi APPGUID={0CC618CE-F36A-415E-84B4-FB1BFF6967E1}

The value passed to APPGUID is your specific product code. A product code must be created when using Microsoft Installer to bundle your application setup program.

Introducing SQL Native Client (SNAC)

By now you may have heard of a new data access technology called “SQL Native Client” that will ship with SQL Server 2005. But before we go much further in discussing it, let’s be clear about what we mean by “new”. It is new in that this data access library did not exist prior to SQL Server 2005, but rest assured that it is not some radical new design for accessing data!

In a nutshell, SQL Native Client is a stand alone data access Application Programming Interface (API) that is used for both OLE DB and ODBC. It combines the SQL OLE DB provider and the SQL ODBC driver into one native dynamic link library (DLL) while also providing new functionality above and beyond that supplied by the Microsoft Data Access Components (MDAC). SQL Native Client can be used to create new applications or enhance existing applications that need to take advantage of new SQL Server 2005 features such as Multiple Active Result Sets (MARS), User-Defined Types (UDT), and XML data type support.

So SQL Native Client combines OLE DB and ODBC in one library, and then enhances that library to take advantage of new features offered by SQL Server 2005. Hopefully that is straightforward enough. But we imagine that this leads to a few questions such as “why have you done this?” and “when would I want to use it?” We’ll try to address those questions next.

Why have you done this?

The reason we have developed SQL Native Client is to allow us to continue to innovate OLE DB and ODBC functionality without being restricted by the constraints imposed by MDAC. MDAC now ships as a component of the Windows operating system and as such there are a number of setup, redistribution, and deployment issues that have occurred as a result of this. How many of you have installed a Windows service pack only to see your MDAC based application break? Or perhaps you have developed an application based on the latest MDAC release only to discover that when you deploy it, the users in your organization do not have the latest MDAC release so your app won’t function correctly. By wrapping the OLE DB and ODBC technologies into a single library, we are able to avoid these issues by making a clean break from MDAC so that you can effectively deploy SQL Native Client as needed, without concern about if it will “play nicely” with other versions of MDAC.

When would I want to use it?

But when would you actually want to use SQL Native Client as opposed to MDAC, or even ADO.NET? The answer is – only if you are upgrading existing or developing new COM-based (or native) applications that will target the new features of SQL Server 2005. If you don’t need any of the new features of SQL Server 2005, then you don’t need to use SQL Native Client, your existing OLE DB and ODBC code will work just fine. Of course, if you have or are planning on moving to a managed code base for data access, then the ADO.NET data access classes of the .NET Framework is what you should use.

More Information?

We’ve barely scratched the surface here of how you can use SQL Native Client, but hopefully you now understand what it is, where it fits in with the various other data access technologies, and when and where you would want to use it. Over the next few months you will see more and more information posted about SQL Native Client, but please let us know what questions and concerns you have. We currently have a number of articles and whitepapers in development, and we’d love to have your feedback to help shape the direction that they take.

You can download the SNAC 10.5 from this location :
x86 version - go.microsoft.com/fwlink
x64 version - go.microsoft.com/fwlink