When to Use SQL Server Native Client
SQL Server Native Client (SNAC) is not supported beyond SQL Server 2012. Avoid using SNAC in new development work, and plan to modify applications that currently use it. The Microsoft ODBC Driver for SQL Server provides native connectivity from Windows to Microsoft SQL Server and Microsoft Azure SQL Database.
SQL Server Native Client is one technology that you can use to access data in a SQL Server database. For a discussion of the different data-access technologies, see Data Access Technologies Road Map
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. If you don't need access to the new features of SQL Server, you can continue to use Windows Data Access Components (WDAC).
For existing OLE DB and ODBC applications, the primary issue is whether you need to access the new features of SQL Server. If you have a mature application that does not need the new features of SQL Server, you can continue to use WDAC. But if you do need to access those new features, such as the xml data type, you should use SQL Server Native Client.
Both SQL Server Native Client and MDAC support read committed transaction isolation using row versioning, but only SQL Server Native Client supports snapshot transaction isolation. (In programming terms, read committed transaction isolation with row versioning is the same as Read-Committed transaction.)
For information about the differences between SQL Server Native Client and MDAC, see Updating an Application to SQL Server Native Client from MDAC.