DataRelation. This object represents a parent-child relationship between two tables. Columns, which must have the same data type, establish relationships. Columns don't have precise cardinality and can be 1:1, one-to-many (1:M), or many-to-many (M:N). Relationships can also easily cascade changes from parent rows to children, although this behavior isn't the default.
To enable the DataRelation object, you need to add a ForeignKeyConstraint to the ConstraintsCollection member of the data table you plan to change. The ConstraintsCollection of the DataTable object determines what happens when a value in a parent table is deleted or updated.
After you set up the relationship, ADO.NET disallows any dataset change that would break the relationship and creates a runtime exception. While walking through a table's rows, you can call the GetChildRows method to access all the related rows from a connected table. The GetChildRows method returns an array of DataRow objects, an alternative navigation type that follows a hierarchical model, instead of the traditional sequential or random-access model.
Relationships aren't transitive. Suppose that Table A relates to Table B and Table B relates to some rows in Table C. Further, suppose that you're scrolling through the records in Table A and for each record, you access the child rows in the existing relation. If you also want to access the child rows in Table C for a given row in Table B, you can't use the DataRow object on Table B that the A-to-B relation provides. Instead, you must open a new table view from Table B, locate the specific record you want, then call GetChildRows through Table B's relation with Table C.
The code in Listing 1 shows you how to create and fill a DataSet object by accessing the standard Northwind database in SQL Server. As you saw earlier, Figure 2 provides a quick view of the hierarchy below the DataSet object. After you create a DataSet object, you open a connection to the chosen database and execute a command that returns records. This command can be one SQL statement, as well as a stored procedure. The following code shows the FillDataSet method, which lets you associate with the specified dataset the table that the command returns:
Dim oDS As New DataSet
oCMD.FillDataSet(oDS, "EmployeesList")
Each table in a dataset has a name that you use to retrieve the content. ADO.NET's real step forward comes with dataset creation. ADO.NET's DataSet object has no ADO counterpart. Although this example might fail to show the DataSet object's importance, architecturally speaking, the DataSet object is at a different level. The possibility of managing more tables at once under the same logical object's umbrella provides unprecedented power for implementing master-detail schemas and data-bound architectures. You can also reference a table by index.
Modifying Data
When working disconnected, you modify data by adding, modifying, or deleting rows from an in-memory cache. So, if you add a new record to a DataTable by using NewRow or edit the values of an existing record with a simple assignment, the changes occur in memory and don't affect the underlying data source. The update occurs when you call the Update method from a Command object to submit the changes. The Update method calls the respective insert, update, or delete commands for each inserted, updated, or deleted row in the dataset.
You specify data-source-specific commands to insert, update, or delete records by using the ADO.NET Command object's InsertCommand, UpdateCommand, and DeleteCommand properties. The content of these properties depends on the specific data provider you're targeting, but if the data provider is a database management system (DBMS), the content is likely to be SQL strings. During the Update method's execution, if any of these properties isn't set but the DataSet object contains primary key information, ADO.NET automatically generates the command text.
I recommend using this insert, update, and delete approach only when the application requires that you load a certain number of records and apply changes in an unpredictable order and number. If the UI merely requires you to populate some fields, then insert or update a record, executing a SQL statement or launching a stored procedure is preferable.
Other Considerations
Although ADO.NET isn't a particularly huge topic, this article only scratches its surface. You can't effectively use ADO.NET without first understanding the rationale behind it. ADO.NET isn't merely another API for accessing data; ADO.NET lets you access data across the Web while you leverage the power of the .NET platform. If you choose .NET for your server, you should adopt ADO.NET for data access.
When designing the .NET platform, Microsoft had to decide how to handle data access. The company could have ported ADO as is, but ADO is COM-based and mostly used as a script interface on top of OLE DB, a tightly coupled and connected environment. Microsoft modified the ADO model to make it less database-centric and more able to work in a loosely coupled environment. In ADO.NET, Microsoft made ADO consistent with the .NET platform. Whether you write Web forms, Windows forms, or Web services, if you have a data source in your system, ADO.NET always presents the same set of classes. ADO.NET revisited the Recordset object and split its functionality into two objects: DataSet and DataReader. If you decide to stick to ADO, you can still use .NET to import ADO classes. However, ADO provides nothing that ADO.NET can't do.
Another important consideration concerns the way that Microsoft designed ADO.NET. In both ASP.NET and ADO.NET, most changes reflect programming best practices. Microsoft simply inserted the changes into a consistent object model and an all-encompassing framework where the individual programming trick emerges as an integrated functionality. As the offspring of common best practices and common user requirements for data access, ADO.NET qualifies as an absolute must if you want to upgrade your Web systems to .NET.
End of Article
Prev. page
1
2
3
[4]
next page -->
