Introducing SQL Native Client

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.


And by the way, be sure to check out the Data Access Technologies Roadmap on MSDN for the complete story and status for the majority of data access technologies here at Microsoft.

Acey J. Bunch

Lead Programmer Writer - DataWorks User Education.

Disclaimer: This posting is provided "AS IS" with no warranties, and confers

Comments (20)
  1. What sort of performance can we expect to see out of it compared to using ADO?

  2. I hope the next version of MDAC replaces the current libraries with the SQL

    Native Client. …

  3. Chris Lee - Program Manager SQL Native Interfaces says:

    MDAC and SQL Native Client are separate components with separate development paths. SQL Native Client supports only the ODBC and OLE DB APIs for SQL Server, and will be updated only in SQL Server releases and service packs. MDAC continues to provide core data access services (such as OLE DB Service Components and ODBC Driver manager) for all drivers/providers including SQL Native Client. MDAC will be updated only in Windows releases and service packs in the future. There won’t be any ‘crossover’ between SQL Native Client and MDAC. MDAC will not be getting feature enhancements in the future, but it will get bug fixes and enhancements to improve security and serviceability.

  4. Chris Lee - Program Manager, SQL Native Interfaces says:

    ADO users can expect to get similar performance with SQL OLEDB and SQL Native Client, though individual apps may show differences either way depending on what they do.

  5. Eric Newton says:

    Is the SQL Native client going to be able to pass CLR arrays into CLR sprocs? THAT is reason enough to change over.

    as far as I know, the only way to send an int[] (for example, a list of id’s to work on) is to stringize them to a varchar(max) comma separated list… BLEH for more than 100 elements, the bloat is awful…

    In addition, will the native client also be able to support database engine events? And "closer to the metal" support? ie, being able to get a little closer to the actual data processing internals of sql server?

    that would be cool. (of course probably abused, but hey, just write "best practices" 😉

  6. Chris Lee [MS] says:

    If you need to pass CLR objects into CLR sprocs the best approach is to use SqlClient.

    We want to see SQL Native Client evolve to maximize the potential for native applications to get the most out of SQL Server. Streamlining the architecture for better performance and exposing new server capabilities are definitely in our plans. However, we want to provide great peformance without developers having to jump through too many hoops, so keeping the programming model as simple as requirements allow is also in there too.

  7. smueller66 says:

    How does the SQL Native Client implement asynchronous calls?

    What I’m really interested in, is if its using overlapped I/O and completion ports.

  8. As Acey Bunch explained in April, SQL Native Client meets the needs of developers wanting to take advantage…

  9. As Acey Bunch explained in April, SQL Native Client meets the needs of developers wanting to take advantage…

  10. Raymond says:

    SQL Server 2005 documentation ( states the following:

    "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 that is part of the .NET Framework for Visual Studio 2005."

    Does that mean that ADO.NET 2.0 uses SQL Native Client as its SQL OLE DB provider?

    You can tell I’m confused 🙂

  11. Dave Patrick says:

    I do a lot of Access programming using linked tables to SQL server. Should I start using SQL Native Client?

  12. Himadrrish says:

    How can we get a sql 2005 client interface. Just like to connect to server and query on table. Is there any such interface avilable in sql 2005 client intallation?

  13. Getting started with SQL Native Client [Chris Lee]

    [This was originally posted on the DataWorks blog…

  14. Upgrading a SQL Server database should be straight-forward, when you haven’t got much of constraints

Comments are closed.

Skip to main content