My understanding from reading the documentation of the CommandBuilder object is that it takes a "select statement" as a template for an in-memory client-side result set and by preparing the select statement then retrieves a crapload of data about the columns and sources and inspection of the indexes associated with each item in the select list to determine the "candidate keys" so that it can automagically generate the rest of the CRUD statements. That is given the "R" it will automagically generate the "CUD" statements that will make the in-memory result set consistent with the actual source rows. This would mean that the time taken is proportional to the number of columns in the select and the number of indexes in which those columns participate. While this may be an efficient crutch for the inherently incompetent, I would consider such practices to be inherently unsound. This is the "sort of shit" that causes almost everything designed by Microsoft or using dot Snot to be slower than molasses running uphill in an Edmonton winter -- such things as the various Microsoft Active Directory tools in which you need to open them the week before you need to use them, and only on a machine with gigabytes of RAM, because the idiots that designed that crap are used to "itty bitty" directories and programs with 3 products and 5 customers but that totally fall to bits and are completely unusable when presented with "real world" data.