Native API for SQL Server FAQ Beginning in SQL Server 2005, Microsoft changed the way it supports ODBC and OLE DB with the introduction of a component called Microsoft SQL Server Native Client. This FAQ answers some basic questions about SQL Server Native Client and about ODBC and OLE DB in general. Q. What is SQL Server Native Client? A. Microsoft SQL Server Native Client is a single native dynamic link library (DLL) that contains the ODBC driver and OLE DB provider, which together support applications using native-code APIs (ODBC, OLE DB and ADO) to access Microsoft SQL Server. SQL Server Native Client is a component of SQL Server. It is also available for download from the Feature Pack for Microsoft SQL Server 2005 and Microsoft SQL Server 2008 Feature Pack. In SQL Server Native Client, everything (APIs, TDS routines, and netlibs) is packaged into a single DLL. Previously, ODBC and OLE DB support for SQL Server was provided via Microsoft Data Access Components (MDAC). MDAC is now fully integrated into Windows and is available only in Windows releases and service packs. There will be no more standalone MDAC downloads on MSDN. MDAC continues to provide core data access functionality such as ADO, the ODBC Driver Manager, and OLE DB Core Services, but the ODBC and OLE DB support for SQL Server is frozen at the level of functionality provided by SQL Server 2000. Note that SQL Server Native Client supports SQL Server releases from SQL Server 7.0 onwards, so its use is not restricted to SQL Server 2005. However, new features such as MARS are only available when connected to SQL Server 2005, or later. Q. Where do I find out more about SQL Server Native Client? A. You can find information about SQL Server Native Client in SQL Server Books Online and also at Learning SQL Server Native Client. For anything you can’t find there, you can use the MSDN SQL Server Data Access forum or the Microsoft SQL Server Native Client blog. Q. Must I upgrade clients to use SQL Server Native Client as soon as I upgrade my server? A. Applications deployed before SQL Server 2005 was released can and should continue to use MDAC. Applications must upgrade to take full advantage of the new features and data types introduced in SQL Server 2008. When an application is upgraded, it should be thoroughly tested since there are some differences in behavior between MDAC and SQL Server Native Client. The vast majority of applications will not be affected by these changes, but this does not remove the responsibility to test before deployment. Q. Should I rewrite my native API applications to use ADO.NET and managed code? A. In most cases the old adage "If it isn’t broken, don’t fix it" applies. The .NET platform has many compelling attributes and will be the right choice for new development in most cases, but there could be valid reasons for making other choices. For example, Visual Studio and C++/CLI (introduced in Visual C++ 2005) make re-use of existing native data access code within a .NET deployment infrastructure a more viable option than ever before; there are some scenarios where native code and native APIs provide the best solution; Microsoft now has its own high-quality JDBC driver for SQL Server 2005. Q. Isn't ODBC is on the way out? If you have to use a native API isn’t OLE DB better? A. ODBC and OLE DB are supported equally in SQL Server Native Client. Neither is better—they service different requirements and communities. There is no need to convert from one to the other unless there are other compelling business reasons. While there was a time when Microsoft expected OLE DB to supersede ODBC, that time has passed and we now recognize that each API has its place. OLE DB is a good choice for COM applications and has broader functionality than ODBC in some areas. It is used extensively within SQL Server itself. However, it is quite complex and more difficult to program for basic operations than ODBC. ODBC may have been out of the limelight in recent years, but Microsoft anticipates strong and continued interest in this API going forward. ODBC has a huge following across the entire software industry and will therefore remain an essential component of SQL Server to meet requirements for standards alignment and interoperability. When migrating applications from other databases to SQL Server, where companies choose to re-use existing code and applications rather than make a fresh start and re-develop from scratch, ODBC will be the natural choice in most cases. There is little difference in performance between OLE DB and ODBC. Application architecture is likely to have a bigger impact on performance than choice of API for well-written applications that follow best practice guidelines. Q. ODBC is a "wrapper" API and is inherently inefficient, right? A. This may be true for some ODBC drivers, but not for SQL Server Native Client. ODBC in SQL Server Native Client and also in MDAC is a true native API for SQL Server. Q. What about DB-Library and Embedded SQL for C (ESQL/C)? A. DB-Library and ESQL/C components are not included in SQL Server but connections from existing applications are supported. Microsoft has no plans for any new development work involving these APIs. Customers may continue to deploy existing applications, but development of new applications and extension of existing applications is not recommended. Continued support for DB-Library and ESQL/C is not guaranteed in future releases of SQL Server.