Now this one seems to be a huge topic, but have no fear, we’ll overcome it. The “may include, but is not limited to” section says: update data by using stored procedures, update DataSets to data source, managing concurrency.
Updating data by using stored procedures is not the hardest task in our lives. Simply build a SqlCommand object, set the CommandType to StoredProcedure, and use parameters (always use parameterized SQL commands, because SQL injection attacks will haunt you in your dreams if you wouldn’t do so). I think this one is out.
To update DataSets (and all the related stuff) is a bit more complicated. You should use DataAdapters (or TableAdapters, strongly typed or not) to solve this issue. DataAdapters expose some properties related to updated data, such as UpdateCommand, or DeleteCommand and InsertCommand. If you remember what I wrote about the states of DataRows, you can easily put the pieces together. If not, here’s a brief refresher:
When you call the Update method of the DataAdapter, it will treat DataRows differently, based on their RowState property. On the ones marked Deleted, it will call the DeleteCommand. In a similar way, Modified rows will be processed by the UpdateCommand, and Added will be by the InsertCommand. Watch out of this, because there may be exam questions lurking out there on this topic.
As mentioned earlier (lot earlier), the DataAdapter automatically generates commands for delete, insert and update, based on the select command specified. Of course, you can write your own custom commands (stored procedures, for example). SqlAdapter has a useful property, called UpdateBatchSize. By setting it to a specified value, the adapter will send that many rows in a round-trip to the server. Thus setting it to a greater value will result in fewer round-trips, and better performance.
We’ll examine the topic of concurrency in the yet-to-come post about managing data integrity, so stay tuned.