I’m a person who always likes to know where things live in the OS, database, or whatever product I’m dealing with. Being able to point to a specific DLL or configuration file or registry entry gives me something tangible to hang my hat on, rather than think that things happen “by magic”.
So I was intrigued by the apparent disappearance of the network libraries in SQL Server 2005. Start with these points:
1. SQL Server 2005 B2 does not ship a new version of MDAC
2. SQL Server 2005 B2 does ship with SQL Native Client (codename was SNAC) with new OLE DB provider and ODBC driver. It also appears to cover network connectivity. In the new client config utility, all (four) supported protocols list netlibs as “SQLNCLI.dll”. That's SQL Native Client.
3. System.Data.SqlClient does not use MDAC any more
4. System.Data.SqlClient did use DBNETLIB.dll to talk to SQL Server in the past
So does .NET SqlClient use SQL Native Client? Dan, Niels, and I did some experiments and it doesn’t appear that SqlClient calls SNAC at all. We even installed .NET 2.0 on a machine without SNAC and did tests that include MARS and async (these require new protocol features). Worked fine, no SQLNCLI or DBNETLIB loaded or in sight. So how’d they do that?
Looking in System.Data.dll, it appears that there are some calls that start with the letters SNI. There are no calls to DBNETLIB (as there was in System.Data.dll in .NET 1.1). A quick search of Books Online yielded only references to SNI associated with Service Broker protocol (as in “the SNI connection string for Service Broker…”).
So it appears that both System.Data.dll and SQLNCLI.dll implement SNI calls directly rather than calling a specific library. And that the SNI model is used by more than just client-server protocols. It is possibly used for everything that is covered by CREATE ENDPOINT. System.Data.SqlClient doesn’t use MDAC or SNAC, but both System.Data.SqlClient and SNAC are compatible with previous versions of SQL Server, because I could use the OLE DB Native Client provider with SQL Server 2000 just fine. Hmmm.
One thought on “Where did the netlibs go?”
Great catch! This is IMO one of the best improvements in ado.net 2.0. SqlClient no longer relies on external netlibs because the right version of the netlibs has been baked into System.Data.
This allows us to guarantee that features that are netlib dependant like Async and Mars always work (for SqlClient only, Oledb MARS to Sql Server is still netlib dependent. This dependency is so bad that I have to strongly suggest people to avoid using Oledb to connect to Sql Server)
There is one exception, when using SqlClient we will still use the netlibs when connecting to Sql Server 2000 or lower using shared memory. To make Async work in this scenario you need to either force a tcp connection to your local server. http://weblogs.asp.net/despos/archive/2004/07/22/190984.aspx#FeedBack
Comments are closed.