Once you're certain that the reference to the DLL is present, it's also a good idea to add an Imports statement for System.Data.OleDb, System.Data.SqlClient or other namespace to your project to make it easier to write correct code. (These will be discussed in later articles in this series.) There is so much confusion on this point that a special DYK article has been written for this tutorial to make sure you understand it. If you have any questions at all about what the Imports statement does, read through this DYK carefully.
The objects that are in ADO .NET are roughly split into two groups content components and managed-provider components. The content components essentially hold actual data and include these classes:
- DataSet
- DataTable
- DataView
- DataRow
- DataColumn
- DataRelation
The managed-provider components interact with the database for data retrievals and updates. These components include:
- connection
- command
- data adapter
- data reader
The names above are "generic" (note that they're not capitalized) because unique managed-provider components are used with different "providers" (software interfaces for actual databases). There are two that are currently included with ADO .NET. SqlClient is used with Microsoft's SQL Server database and OleDb for everything else. For example, SqlClient contains SqlDataReader and OleDb contains OleDbDataReader.
Right now, only SQL Server has native support through an ADO .NET managed provider. But since there is a lot of data in other data sources, Microsoft has supplied an ADO .NET managed provider for OLE DB (in the System.Data.OleDb namespace). If a data source has OLE DB data provider, ADO .NET can work with it. Since there is an OLE DB provider that wraps the even older ODBC, ADO .NET can work with almost all legacy data, regardless of the source.
Next page >
DataSet - King of ADO .NET Objects > Page
1,
2,
3,
4
| 