Thank you. Microsoft makes no warranties, express or implied, with respect to the information provided here. The DataSet used to update the data source. The number of rows successfully updated from the DataSet. The update is performed on a by-row basis. For every inserted, modified, and deleted row, the Update method determines the type of change that has been performed on it Insert, Update or Delete.
Depending on the type of change, the Insert , Update, or Delete command template executes to propagate the modified row to the data source. It should be noted that these statements are not performed as a batch process; each row is updated individually.
NET Framework data provider. This generation logic requires key column information to be present in the DataSet. For more information see Generating Commands with CommandBuilders.
The Update method retrieves rows from the table listed in the first mapping before performing an update. The Update then refreshes the row using the value of the UpdatedRowSource property.
Any additional rows returned are ignored. After any data is loaded back into the DataSet , the OnRowUpdated event is raised, allowing the user to inspect the reconciled DataSet row and any output parameters returned by the command. After a row updates successfully, the changes to that row are accepted. When using Update , the order of execution is as follows:.
The values in the DataRow are moved to the parameter values. The OnRowUpdating event is raised. If the command is set to FirstReturnedRecord , then the first returned result is placed in the DataRow. I have only set the InsertCommand as I am only adding rows, if you are updating and deleting rows then UpdateCommand and DeleteCommand must be set also.
For each row that was updated the UpdateCommand will be called, for the new rows InsertCommand will be called and for rows that have been deleted the DeleteCommand will be executed. The CommandBuilder class allows the developer to get away from worrying about the detail of SQL and concentrate on the other things. But there are a few things to think about before using the CommandBuilder.
One of the tradeoffs is speed as the dynamically generated SQL from the CommandBuilder might be slower than using stored procedures for data access. The CommandBuilder also has to make an extra call to the database to retrieve the schema information for the Database Table. Another issue is that the programmer also does not have any control over the SQL that the CommandBuilder generates, so if you do not like the SQL there are not many options. As a minimum requirement, you must set the SelectCommand property in order for automatic command generation to work.
As a result, an extra trip to the data source is necessary, and this can hinder performance. To achieve optimal performance, specify your commands explicitly rather than using the DbCommandBuilder. The SelectCommand must also return at least one primary key or unique column. If none are present, an InvalidOperation exception is generated, and the commands are not generated.
If a Command already exists for a property, the existing Command is used. Database views that are created by joining two or more tables together are not considered a single database table. In this instance you cannot use the DbCommandBuilder to automatically generate commands; you must specify your commands explicitly.
For information about explicitly setting commands to resolve updates to a DataSet back to the data source, see Updating Data Sources with DataAdapters. You might want to map output parameters back to the updated row of a DataSet. One common task would be retrieving the value of an automatically generated identity field or time stamp from the data source. The DbCommandBuilder will not map output parameters to columns in an updated row by default.
In this instance you must specify your command explicitly. For an example of mapping an automatically generated identity field back to a column of an inserted row, see Retrieving Identity or Autonumber Values.
The logic for generating commands automatically for UPDATE and DELETE statements is based on optimistic concurrency --that is, records are not locked for editing and can be modified by other users or processes at any time. This is done to avoid overwriting new data. Where an automatically generated update attempts to update a row that has been deleted or that does not contain the original values found in the DataSet , the command does not affect any records, and a DBConcurrencyException is thrown.
0コメント