Updating a Data Source Using Custom Logic
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:
- Stored procedures
Most significant applications use stored procedures because of their benefits, which include maintainability, security, and performance over SQL statements.
- Table joins
In some cases, table joins are needed to retrieve aggregate information. However, even if you edit only fields from a single table, the
CommandBuildercan’t automatically generate the
- More flexible concurrency handling
The UPDATE and DELETE statements generated by the
CommandBuildersearch 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 ideal.
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 ...