Working with DataSets

Team Fly 

Page 415

This query will return two cursors, one with the selected rows of the Products table and another one with the selected rows of the Suppliers table. While you can't use this batch query to populate a DataSet with two tables (you must set up two different DataAdapters, one for each table, and call their Fill method), you can retrieve the rows from both tables with a DataReader object. You start reading rows as usual. When you reach the end of the first cursor, call the DataReader's NextResult method to move to the following cursor:

 Do     While RDR.Read()     ' statements to process the rows of the current cursor     End While While RDR.NextResult() ' skip to next cursor, if there is one 

The first time through the outer loop, the inner loop reads the rows of the Products table. When the NextResult method is called, you're into the second cursor and the inner loop is executed again, this time reading the rows of the Suppliers table.

Working with DataSets

Now that you know how to contact a database and execute commands against it, we can examine the DataSet object in detail. This is the main object of ADO.NET and this is where most applications store data at the client. The DataSet is made up of DataTable objects; there's one DataTable for each one of the tables involved in the query. The DataTable objects are made up of DataColumn and DataRow objects. The DataColumn objects specify the structure of the table, and the DataRow objects contain the rows of the table. You can also establish relations between the tables in the DataSet; these relations are represented with DataRelation objects.

As you already know, we use DataAdapters to fill DataSets. It's possible to create a DataSet and also fill it from within your code, but this isn't common. Most often, DataSets are generated at design-time and populated at runtime with the DataAdapter's Fill method. These DataSets are called typed DataSets, because they know about the structure of the data they store. Notice that only DataSets created at design time are typed. This happens because the IDE generates a class behind your back to encapsulate the data and the basic operations you can perform on the data. A DataSet generated at runtime won't expose the names of its tables as properties and it won't provide methods that are specific to your data (such as the FindByCustomerID method, or the IsUnitPriceNull property) for example).

By the way, if you want to see the code of the class that implements a typed DataSet, click the Show All Files button at the top of the Solution Explorer window and then expand the file named after the DataSet (its extension is XSD). Under this file you'll see two more files, which are normally hidden, and they're both named after the DataSet. Double-click the file with extension VB and you'll see the code of the class that implements the typed DataSet. Figure 15.9 shows a section of the DSProducts.vb class, which is part of the NWProducts project. As you can see, there's nothing complicated or magic about typed DataSets. They're implemented with code that some of us might have written to simplify the process of coding large projects, only this code was generated by a wizard. Normally, you'll never have to see the auto-generated code, unless you want to add a few members that are specific to an application. Even so, you should implement these members in a separate class, because every time you redesign the DataAdapter and re-generate the DataSet, this class is auto-generated.

Team Fly 


Visual Basic  .NET Power Tools
Visual Basic .NET Power Tools
ISBN: 0782142427
EAN: 2147483647
Year: 2003
Pages: 178

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net