Visual Basic: RDO Data Control
WillUpdateRows Event
See Also Example Applies To
Occurs before an update to the database occurs.
Private Subobject**.WillUpdateRows**(ReturnCode as Integer)
The WillUpdateRows event syntax has these parts:
| Part | Description |
| object | An object expression that evaluates to an object in the Applies To list. |
| ReturnCode | An Integer expression or constant indicating whether the developer handled the update or not as described in Settings. |
The ReturnCode argument is used to notify RDO about what your code did during the event handling. The possible values for this argument are as follows:
| Setting | Description |
| rdUpdateSuccessful | Your code handled the update and was successful in doing so. |
| rdUpdateWithCollisions | Your code handled the update successfully, but some rows produced collisions (batch mode only). |
| rdUpdateFailed | Your code attempted to handle the update, but encountered an error when doing so. |
| rdUpdateNotHandled | Your code did not handle the update. RDO should continue notifying and if no one handles the update, RDO should update the data itself. |
Remarks
The WillUpdateRows event is raised before updated, new and deleted rows are committed to the server. You can override the update behavior of the cursor by responding to this event and perform your own updates using stored procedures or any other mechanism you choose.
If the result set is using batch optimistic concurrency, this event is only raised when the BatchUpdate method is called. In this case, the entire set of changes is about to be transmitted to the server.
If the result set is not in a batch mode, the WillUpdateRows event is raised for each call to the Update method, since the changes for that row are immediately sent to the server.
To summarize, no matter what mode the result set is in, this event is only raised before data is actually sent to the server.
If you set the ReturnCode argument to rdUpdateSuccessful, RDO assumes that your code successfully handled the update. RDO will not send this event to any additional clients (if there is more than one handler of this event) and the status for the row(s) and their columns is set to rdRowUnmodified and rdColUnmodified respectively.
If you set the ReturnCode parameter to rdUpdateWithCollisions, RDO assumes that you have successfully handled the update, but some rows caused collisions. RDO will not send this event to any additional clients (if there was more than one handler of this event) and the status for the rows and their columns is not changed. It is your code's responsibility to set the column status flags during the handling of this event. The rdUpdateWithCollisions would only be used if you are using batch optimistic concurrency and you wanted to check for and handle collisions in code.
If the developer sets the ReturnCode parameter to rdUpdateFailed, RDO assumes that your code attempted to handle the update, but encountered an error while doing so. RDO will not send this event to any additional clients (if there was more than one handler of this event) and the status for the row(s) and their columns remains unchanged. Finally, RDO generates a runtime error to be trapped by the Update method causing the WillUpdate event to fire.
If you set the ReturnCode parameter to rdUpdateNotHandled, RDO will assume that the developer did not handle the update, and RDO will continue to raise this event to all remaining clients (if there was more than one handler of this event). If all clients return rdUpdateNotHandled, RDO will perform the update itself, according the normal rules.
The default value for the ReturnCode parameter is rdUpdateNotHandled, so if no client sinks the event, or no client changes the value of ReturnCode, RDO will perform the update.