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
Anonymous
April 26, 2005
What sort of performance can we expect to see out of it compared to using ADO?Anonymous
April 26, 2005
I hope the next version of MDAC replaces the current libraries with the SQL
Native Client. ...Anonymous
April 26, 2005
The comment has been removedAnonymous
April 26, 2005
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.Anonymous
April 26, 2005
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" ;-)Anonymous
May 04, 2005
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.Anonymous
May 30, 2005
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.Anonymous
July 29, 2005
As Acey Bunch explained in April, SQL Native Client meets the needs of developers wanting to take advantage...Anonymous
July 29, 2005
As Acey Bunch explained in April, SQL Native Client meets the needs of developers wanting to take advantage...Anonymous
April 06, 2006
SQL Server 2005 documentation (http://msdn2.microsoft.com/en-us/library/ms130828(SQL.90).aspx) 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 :-)Anonymous
June 05, 2006
I do a lot of Access programming using linked tables to SQL server. Should I start using SQL Native Client?Anonymous
June 21, 2006
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?Anonymous
September 27, 2006
Getting started with SQL Native Client [Chris Lee]
[This was originally posted on the DataWorks blog...Anonymous
January 25, 2008
Upgrading a SQL Server database should be straight-forward, when you haven't got much of constraintsAnonymous
January 20, 2009
PingBack from http://www.hilpers.com/355689-sql-server-2005-und-vb6Anonymous
January 21, 2009
PingBack from http://www.keyongtech.com/2073953-version-of-mdac-for-sqlAnonymous
May 31, 2009
PingBack from http://outdoorceilingfansite.info/story.php?id=5157Anonymous
May 31, 2009
PingBack from http://outdoorceilingfansite.info/story.php?id=22793Anonymous
June 15, 2009
PingBack from http://edebtsettlementprogram.info/story.php?id=21878Anonymous
June 16, 2009
PingBack from http://fixmycrediteasily.info/story.php?id=16881