Dataset Table Manager Update Order of Operation Significance RRS feed

  • Question

  • Well,

    This is a theory question, that perhaps someone might shed some light on since I've been thinking about the significance of how (and why) the Generated TableAdapterManager behaves in a specific manner.

    If you've ever used the Dataset Designer from a SQL Server Database, you know that a TableAdapterManager (TAM) class is created to manage all the TableAdapters for the Datasets DataTables.  The Segment of interest is the Update(dataset) method of the TAM.  In this method, when you peruse the designer.vb class file, you see that it proceeds to normalize all the TableAdapter's connections, and verifies that each connection is valid (open), etc.  It then proceeds to preserve all the Inserted, Deleted, and Modified rows of each table contained by the Dataset, and then, based upon a property, it performs all the Update() commands, then all the Insert() commands, and then all the Delete() commands for each row per TableAdapter. 

    So we have 3 tables, each with a few modified rows of all varieties, and we call update on the dataset via the TAM, and all the rows are preserved in the database.  I rather understand this, but as I have created my own dataset/manager library, which is far more robust than the .Net original, I originally mirrored this pattern.  But I am curious as to why it is done this way?

    I get the normalization of the COnnections, and maintaining a single "one fell swoop" mentality to committing the altered dataset data back to the underlying database.  But why Cycle through all the Adapters and run the SQlDbCommand.Update() method on all the Modified rows, then cycle through all the adapters again and run the SQLDbCommand.Insert() method on all the Added rows, and so on and so forth.

    Why Not cycle through all the Adapters and simply call out to Adapter.Update(Table)?  Or if by using the collection of rows unassociated with the tables is "cleaner" some how, why not still perform a cycle through all the adapters and then perform the individual commands per adapters rows, instead of cycling three different times for each operation?

    I simply question this because I see many ways to go about handling the "Commit" of all dataset data back to the database, and wondered if there was some significance to why the .Net default style was chosen.  Is it faster for the SQL Server Engine to handle 12 Update, 12 Insert, and then 12 Delete statements than to handle 1 Update, 1 Insert, and then 1 Delete statement 12 times in a row?  I am more or less curious about the theory because that will help me keep certain better practices in mind as I affect changes in my own design.


    Jaeden "Sifo Dyas" al'Raec Ruiner


    "Never Trust a computer. Your brain is smarter than any micro-chip."
    PS - Don't mark answers on other people's questions. There are such things as Vacations and Holidays which may reduce timely activity, and until the person asking the question can test your answer, it is not correct just because you think it is. Marking it correct for them often stops other people from even reading the question and possibly providing the real "correct" answer.
    Sunday, August 1, 2010 6:52 PM


  • Hi Jaeden,

    If you use the TableAdapter to update the dataset at one time, it will eventually call the Update(DataRow[] dataRows)  method which is the same with how the TableAdapterManager's TableAdapter does.  TableAdapterManager's TableAdapter use this update method directly with spliting the rows into inserted, Deleted, and Modified. Using TableAdapter to update the dataset will also need to check the row state by looping the rows in the dataset(data table), but this procedure has been done already when using TableAdapterManager by using select method of the data table. You can see all this through Reflctor.

    Best regards,
    Alex Liang 


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Thursday, August 5, 2010 9:22 AM