When to Use SQL Native Client
When deciding whether to use SQL 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# .NET or Visual Basic .NET, and you need to access the new features of SQL Server 2005, you should use the .NET Framework Data Provider for SQL Server, which is part of the .NET Framework for Visual Studio 2005. This will give you the most robust data access component for working with SQL Server 2005.
If you are developing a COM-based application and need to access the new features of SQL Server 2005, you should use SQL Native Client. If you don't need access to the new features of SQL Server 2005, you can continue to use Microsoft Data Access Components (MDAC).
For existing OLE DB and ODBC applications, the primary issue is whether you need to access the new features of SQL Server 2005. If you have a mature application that does not need the new features of SQL Server 2005, you can continue to use MDAC. But if you do need to access those new features, such as the new xml Data Type, you should use SQL Native Client.
Both SQL Native Client and MDAC support read committed transaction isolation using row versioning, but only SQL Native Client supports snapshot transaction isolation. (In programming terms, read commited transaction isolation with row versioning is the same as Read-Committed transaction.) For more information, see Choosing Row Versioning-based Isolation Levels.
For information about the differences between SQL Native Client and MDAC, see Updating an Application to SQL Native Client from MDAC.