What Is a TableAdapter?

Basically, a TableAdapter is a code-generated strongly typed datasource-agnostic interface over underlying SqlClient (or OracleClient, Odbc, or OleDb) namespace objects. The DSCW generates the TableAdapter from whole cloth based on a specified query rowset, so don't go looking for a TableAdapter class in the object browser. However, the TableAdapter class is coded to inherit from the System.Data.DataTable and System.Data. DataColumn classes (as shown in Figure 6.3). This means that the TableAdapter supports all of the methods and properties of the base classes (the DataTable and DataColumn among others).

Figure 6.3. Part of the class used to implement the "AuthorsDataTable" in a TableAdapter.

To manage updates, the TableAdapter is generated using a SqlDataAdapter (or other DBMS-dependent DataAdapter), including hard-coded SelectCommand and (optionally) UpdateCommand, DeleteCommand, and InsertCommand definitions. Ultimately, the TableAdapter is designed to populate a single DataTable through custom Fill and GetTable methods.

Nope, the DSCW does not ask you if you want to use TimeStamp, uniqueidentifier or more intelligent collision-detection schemes, but it does know how to detect a Timestamp column in the SELECT query used as a pattern to generate the code. That is, the generated UPDATE statement tests for post-fetch changes by comparing the current Timestamp value with the Timestamp value initially fetched. This seems to make it a good idea to add a Timestamp column to any database Table that you expect Visual Studio to update using generated code. The generated TableAdapter UPDATE query for the Authors table that includes a Timestamp column is shown in Figure 6.4.

Figure 6.4. Generated UPDATE statement for a Table that includes a Timestamp column.

Incorporating Timestamp concurrency checking is a big step forward. While the DataWorks folks wanted to include even more functionality (to be on par with ADO classic), these features never made it to the final buildsbut I'll talk about that and what you can do to correct these shortcomings a bit later. Note that the generated code is hardly easy for humans to readeven though the DataWorks folks stuck in an extra CR/LF sequence for some reason. I'll talk about managing ADO.NET updates (DML) tasks in Chapter 12 "Managing Updates".

As you'll see later in this chapter, once the DSCW does its thing (and generates all that code), you'll have an opportunity (a duty) to go back in and reconfigure the generated code via a GUI. I'll also talk about the next step later in this chapterdata binding. This is the code needed to connect the data returned by the TableAdapter to one or more bound controls. You'll see how simply dragging icons from the Data Source window to the desktop auto-generates bound controls, navigation controls (to step from row to row), and TextBox controls to capture the input parameters.

What do you get when you step though this process that you could not have achieved with about 50 lines of code that you wrote (or leveraged) yourself? Ah, not much. Yes, the TableAdapter is a fast way to fetch data by nature of its strongly typed foundation, but I expect you'll quickly outgrow it.