By design, the method leaves the Recordset open, and the programmer is responsible for closing it programmatically. This requirement gives you great flexibility because you can load each result set in the Recordset into a distinct DataTable object.
If you just need to load all the result sets into one container object, you use the DataSet object rather than the DataTable. A DataSet is simply a collection of DataTable objects. To import the Recordset into a DataSet object, you use one of the overloads of the Fill method. The overload you see in action in the code below takes a DataSet object and a Recordset object, plus a third argument that I discuss later:
OleDbDataAdapter da =
new OleDbDataAdapter();
DataSet ds = new DataSet();
da.Fill(ds, adoRS, "MyTable");
In the code above, the Fill method automatically closes the Recordset on completion. All the result sets in the original Recordset are available as distinct tables within the DataSet. In this case, though, you have little control over how each DataTable is named. When you call Fill by passing a DataSet object, you can specify a table name—MyTable in the code snippet above. That will be the name of the first table created—that is, the first result set in the ADO Recordset. Additional result sets are automatically named the same as the first one with a number appended—MyTable1, MyTable2, and so on. After the DataSet has been created, you can rename the child tables:
ds.Tables["MyTable1"].TableName = "NewNameOfTable1";
ds.Tables["MyTable2"].TableName = "NewNameOfTable2";
The Middle Tier
The ability to connect to a data-bound control is an important feature of the ASP.NET programming model. Many controls in the .NET Framework—both in the Web Forms and the Windows Forms models—let the data source populate their UI. The data source for such data-bound controls must be a collection object. The ADO Recordset is a collection object, but not a .NET-specific collection object. That's why you need to convert a Recordset into something else (e.g., the DataTable object) to bind to a data-bound control such as the CheckBoxList or the DropDownList. This example illustrates the need to handle ADO and Recordsets with extreme care in .NET code. In Web Forms and Windows Forms, a Recordset can only be an intermediate object that caches data from an OLE DB data provider but can't make it available to specialized data-bound controls.
The OleDbDataAdapter class's Fill method helps you work around this important limitation. This method helps you import into a new .NET application the data that existing business and data-access objects can return: an ADO Recordset. In practice, instead of importing the ADO library, you just import your middle-tier objects into the .NET applications. As long as those business objects return ADO Recordset objects to callers, you can easily convert the Recordsets to ADO.NET objects, then leverage the power of data binding.
As you've just seen, you can import an ADO Recordset into ADO.NET, but the .NET Framework doesn't provide a feature for doing the reverse—exporting a DataTable to a Recordset. So although you can still use ADO to fetch data, you must rely on ADO.NET to perform updates to that data.
A lot of code is written in ADO and VB, and porting it to a new platform and a new language is a serious matter. You can preserve your investments by importing Recordset objects into .NET applications. But in general, using ADO in .NET applications is only a temporary solution. To move to ADO.NET, you need to familiarize yourself with some new objects and concepts. Fortunately, they require a fairly short learning curve if you look at them from a real-world ADO perspective.
End of Article
Prev. page
1
2
3
[4]
next page -->
