ADO.NET NameSpaces are still being invented. ADO.NET NameSpaces offer providers
for specific data sources. OLE DB for the most part is bypassed if you are
using a high end databases such as SQL or Oracle. There is even one on slate
for Exchange Server 2000. Performance has never been better.
SQL Namespace - <%@import namespace="system.data.SQLclient"%>
Why is there a separate namespace just for SQL Server? Simple. The OLE DB providers of traditional ADO were "All things to all data sources" providers. OLE DB was not optimized specifically for any one data source. It was built to work for all data sources. No matter what data source you wanted to access (SQL, Oracle, Access, etc..) you had to go through OLE DB. Which left a lot of people saying "You know, it would be nice if..." But their wishes were merely wishes as the features of OLE DB could not specifically accomodate advanced optimization of any one data source without conflicting with itself. So ADO.NET has gotten around this by offering a bypass to OLE DB and giving you direct access to your data stores with a provider that is optimized specifically for your data source. In time, there will namespaces for other high scale databases such as Oracle. For now we only have the SQL namespace. THE SQLClient namespace contains the .NET Data Objects enhanced for SQL server. MSDN SQLClient NameSpace Support
OleDb Namespace - <%@import namespace="system.data.OleDb"%>
After reading about the SQL Namespace above you should be at the conclusion that the OleDb namespace can be used with any data source but obviously it is meant for low end databases such as MS Access. The ADO namespace contains OleDb .NET Data Objects
MSDN System.Data.OleDb Namespace Support
System.Data - <%@import namespace="system.data"%>
the system.data namespace is the base reference for the ASP.NET Data Objects. You will need to use the system.data for DataBinding and the like.
MSDN System.Data Namespace Support