Mauricio Featherman, Ph.D. Washington St. University Interacting with a Database using Code: DataAdapter’s, DataTables, and DataSets Mauricio Featherman, Ph.D. Washington St. University

Steps to Retrieve Data Web Form Data Adapter or Data Base Connection TableAdapter Data Base Connection Dataset Windows Form Specific file Connection specifies userID, password, database type and name Runs the fill operation (filling the dataset with the required data) RAM-copy of actual data, can contain multiple tables Bound controls display data 2

Steps to Update Data Web Form Data Base Connection Dataset Windows TableAdapter or Data Adapter w/ Command- Builder Web Form Data Base Connection Dataset Windows Form Tables within a dataset have data which needs to be sent to the database The specified database table gets updated DataAdapter- Or TableAdapter performs the SQL updates TableAdapter or DataAdapter uses the connection info to push the changes to the right database and server Form controls are bound to dataset and update data in a dataset 3

ADO.NET Architecture Data Base TableAdapter or DataAdapter Fill dataset with data retrieved from the database The Commands below are used in DataAdapter.Update TableAdapter or DataAdapter DataTables are created, filled with data, and added to the DataSet in the RAM of the PC SelectCommand used in DataAdapter.Fill Data Base Connection Connection String Take updated data from dataset and send it to the database VB forms are used to update the data in the dataset. The dataAdapters sends this in-memory data back to the db. UpdateCommand InsertCommand DeleteCommand

ADO.NET Theory In multi-user databases, often its more efficient for programs to interact with in-memory data rather than interact directly with a database. This is the reason for using dataset’s and the datatable which resides within them When the user wants to push their changes back to the database, the dataAdapter does this very efficiently in batch mode (in bulk). For projects which use code, a dataAdapter does the fetching and updating work. For projects which use a datasource wizard a TableAdapter does the work (their about the same thing)

DataAdapters (DA’s) … Are a bundle of SQLCommands, which fetch the data running a SQL (structured query language) Select command, or update the database using Insert, Delete, or Update commands You have to create dataAdapters telling them which table of data to fetch (the entire table or a subset) (ex: Public shared DA as new SQLDataAdapter(“Select * from Sales”, conn) (ex: Public shared DA as new SQLDataAdapter(“Select * from Sales where Region = ‘West’) ”, conn) Here the database table name is Sales and the connection (conn) is used. (The connection is already connected).

DataAdapter.Fill(DataSet, “DataTableName”) OK what’s the DA doing? Opens the connection to the database Executes the .selectcommand (SQL SELECT statement) of the dataAdapter (probably fetch a subset of the data) Creates a dataTable in the specified dataset passing in the schema from the database table specified in the Select statement, and the tablename you specify Adds the dataTable to the dataset’s table collection (list) Fills the rows collection of the dataTable with the retrieved data from the database Closes the connection to the database

DataAdapter’s best buddy DA’s best friend is the commandbuilder (it’s a helper class) which helps out by generating a lot of code (sweet!) YOU simply need to create the commandbuilder and “connect it” to the DataAdapter (here daJobs) Ex: Public shared New SqlCommandBuilder(daJobs) If you associate a commandbuilder with a dataAdapter, the commandbuilder will auto-generate appropriate SQLCommands for you based on the table’s schema’s

DataAdapter.Update(DataSet, “DataTableName”) OK what’s the DA doing? So when the .update method gets run each row of the dataTable specified in the update statement are examined for changes for added rows the dataAdapter fires its .InsertCommand for modified rows the dataAdapter fires its .UpdateCommand for deleted rows the dataAdapter fires its .DeleteCommand for original unchanged rows the dataAdapter skips to the next row So every row in the dataTable is examined and the appropriate action is taken. Wait! What if the dataTable is hundred’s of thousands of records? Well dataAdapters are insanely fast!

Datasets (DS) DataSets are a container for dataTables so that the dataTables can be related to each other (have foreign key relationships) The dataset holds the structure of each table (column names and data types) and the relationships between them. In a VB project you can see this content looking at the .xsd file. Word of caution, If you use wizards to create a dataset, after doing so, don’t change any column names, data types in your database. The snapshot of the schema (the .xsd file) won’t work anymore. You’ll have to delete all the objects the wizard created. FYI if you have a dataset with 2 tables then you’ll need 2 dataAdapters and 2 commandbuilders.

Datatables The data in Datasets actually resides in the rows of its datatables. The columns collection of the dataTable holds the schema information. This info is the same as stored in the database structure. Once we get the DataAdapter to fill the Datatables of a Dataset, we can bind controls to it using their .datasource property Because the datatables hold the actual data, when dataAdapters fetch data they push it into a dataTable. And, when dataAdapters push updates back to the database they actually look through the rows of the datatable looking for the changes that need to get implemented. OK enough specifics for now!