The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Abstractions and ADO.NET providers

We do a lot of work with mobile devices and we're moving from Java to .NET for this work since there is too little support for Java in this area.  So - I'm learning .NET, and it's looking good.  But....

On this MSDN page about ADO.NET providers:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconwhyadonet.asp

It says:
"The .NET Framework Data Provider for SQL Server uses its own protocol to communicate with SQL Server. It is lightweight and performs well because it is optimized to access a SQL Server directly without adding an OLE DB or Open Database Connectivity (ODBC) layer"

I have minimal experience with SQL Server and took this to mean it uses SQL Servers API.  But a paragraph later, I read this:
"The .NET Framework Data Provider for SQL Server requires the installation of Microsoft Data Access Components (MDAC) version 2.6 or later."

Eh?  Can someone explain this apparant contradiction to me?  How can the provider use it's own protocol and not talk to SQL Server directly if it needs MDAC?

Cheers
Paul
Paul Norrie Send private email
Friday, October 07, 2005
 
 
> The .NET Framework Data Provider for SQL Server uses its own protocol to communicate with SQL Server.
"its own protocol" = "SQL Server's own protocol" not the .NET Framewok Data Provider's own protocol.
So I don't see a contradiction: you need to have components that implement SQL Server's protocol, and these come with MDAC.
Joe
Saturday, October 08, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz