provides an extremely convenient way to create the required
Command objects, but it has definite limitations.
Here are some reasons to avoid the
and use your own custom updating logic:
Most significant applications use stored procedures because of their benefits, which include maintainability, security, and performance over SQL statements.
In some cases, table joins are needed to retrieve aggregate
information. However, even if you edit only fields from a single
automatically generate the
The UPDATE and DELETE
statements generated by the
the data source for a row that matches all fields in the original row
exactly. If any original values have changed, the update will fail
for that row. In some cases, this approach isn’t
There is only one real difference between using the
update logic. The
CommandBuilder generates the
UpdateCommand objects used by the
DataAdapter to reconcile changes made to the
DataSet with the data source. With custom update
logic, those update objects have to be defined.
SourceVersion properties of the
Parameter object bind associate a
Parameter with a
DataAdapter uses these properties to determine
the source of the values within the
DataRow; these values ...