The choice of data provider you make will dictate command-execution methods, as well as the availability of the software "bridge" you need. "Command execution between the different .NET Framework data providers is standardized as much as possible. However, there are differences between the data providers," Microsoft admits.
The SQL Server.NET Data Provider is located in .NET Framework's System.Data.SqlClient namespace. MS recommends the .NET provider for middle-tier applications using Microsoft SQL Server 7.0 or later, as well as for single-tier apps using either the Microsoft Data Engine (MSDE) or SQL Server 7.0.
If you're working with SQL Server 6.5 or earlier, you can't use the .NET framework's built-in data provider. Instead, you must resort to the OLE DB.NET Data Provider, together with Microsoft's OLE DB Provider for SQL Server.
If you're developing middle-tier apps using a non-Microsoft OLE DB database, you're likewise limited to OLE DB.NET Data Provider.
Further, you'd better stick with single-tier apps if you're still relying on MS's Access database. In materials on its Web site, MS admits that "Use of an Access database for a middle-tier application is not recommended."
You'll need to perform yet another download if you want to make use of all of ADO.NET's XML potential. Microsoft's SQLXML 3.0 adds new functionality to previous editions of this software, letting you expose stored procedures and SML templates as Web Services via SOAP. Of course, you'll need SQL Server 2000 in order to enjoy these new features.
If you're using any sort of non-MS database, you're also a download candidate. The upcoming 1.1 edition of .NET Framework is supposed to include both the ODBC .NET Data Provider and the .NET Data Provider for Oracle. Until then, both must be downloaded from the MS Web site.