Hello friends, Today we are going to cover an important aspect of Sql server i.e. connectivity. In this article we’ll cover some basic details of SNAC i.e. Sql Server Native Client.
In this article I’ve used few terms like
Windows Data Access Components, WDAC, Microsoft Data Access Components, MDAC. Please note that all are same. These are synonyms.
What is Sql Server Native Client?
SQL Server Native Client is a stand-alone data access application programming interface (API), used for both OLE DB and ODBC. This was introduced in SQL Server 2005. SQL Server Native Client combines the SQL OLE DB provider and the SQL ODBC driver into one native dynamic-link library (DLL).
It also provides new functionality above and beyond that supplied by the Windows Data Access Components (Windows DAC, formerly Microsoft Data Access Components, or MDAC). SQL Server Native Client can be used to create new applications or enhance existing applications that need to take advantage of features introduced in SQL Server 2005. These new features are multiple active result sets (MARS), user-defined data types (UDT), query notifications, snapshot isolation, and XML data type support.
Note: We’ll discuss about these new features in upcoming articles.
The SQL Server Native Client ODBC driver is always used in conjunction with the ODBC Driver Manager supplied with Windows data access components. The SQL Server Native Client OLE DB provider can be used in conjunction with OLE DB Core Services supplied with Windows data access components, but this is not a requirement. The choice to use Core Services are not depends on the requirements of the individual application (for example, if connection pooling is required).
While SQL Server Native Client uses components in Windows DAC, it is not explicitly dependent on a particular version of Windows DAC. You can use SQL Server Native Client with the version of Windows DAC that is installed with any operating system supported by SQL Server Native Client.
Latest version of native client is 11.
Why we need it?
When deciding whether to use SQL Server Native Client as the data access technology of your application, you should consider several factors.
For new applications, if you’re using a managed programming language such as Microsoft Visual C# or Visual Basic, and you need to access the new features in SQL Server, you should use the .NET Framework Data Provider for SQL Server, which is part of the .NET Framework.
If you are developing a COM-based application and need to access the new features introduced in SQL Server, you should use SQL Server Native Client. And if you don’t need access to the new features of SQL Server, you can continue to use Windows Data Access Components (WDAC).
In case you are upgrading existing or developing new COM-based (or native) applications that will target the new features of SQL Server 2005 then you’ll need SNAC.
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.
How can we deploy?
When deploying an application that is dependent on SQL Native Client, you will need to redistribute SQL Native Client with your application. SQL Native Client is a component of SQL Server 2005. Therefore, it is important to install SQL Native Client in your development environment and redistribute SQL Native Client with your application.
SQL Native Client redistributable installation program name is sqlncli.msi. This is available on the installation media and is available as one of the SQL Server 2005 Feature Pack components on the Microsoft Download site. Below are links for that.
Below are the links to download SQL Server 2012 Native Client
This was very basic introduction of SNAC. We’ll cover more aspects of connectivity in upcoming sessions.