Saves the contents of the copy buffer to an updatable Recordset object.
Syntax
recordset.Update (type, force )
The Update method syntax has the following parts.
Part | Description |
recordset | An object variable that represents an open, updatable Recordset object. |
type | Optional. A constant indicating the type of update, as specified in Settings (ODBCDirect workspaces only). |
force | Optional. A Boolean value indicating whether or not to force the changes into the database, regardless of whether the underlying data has been changed by another user since the AddNew, Delete, or Edit call. If True, the changes are forced and changes made by other users are simply overwritten. If False (default), changes made by another user while the update is pending will cause the update to fail for those changes that are in conflict. No error occurs, but the BatchCollisionCount and BatchCollisions properties will indicate the number of conflicts and the rows affected by conflicts, respectively (ODBCDirect workspaces only). |
Settings
You can use the following values for the type argument. You can use the non-default values only if batch updating is enabled.
Constant | Description |
dbUpdateRegular | Default. Pending changes aren’t cached and are written to disk immediately. |
dbUpdateBatch | All pending changes in the update cache are written to disk. |
dbUpdateCurrentRecord | Only the current record’s pending changes are written to disk. |
Remarks
Use Update to save the current record and any changes you've made to it.
Caution Changes to the current record are lost if:
To edit a record, use the Edit method to copy the contents of the current record to the copy buffer. If you don't use Edit first, an error occurs when you use Update or attempt to change a field's value.
In an ODBCDirect workspace, you can do batch updates, provided the cursor library supports batch updates, and the Recordset was opened with the optimistic batch locking option.
In a Microsoft Jet workspace, when the Recordset object's LockEdits property setting is True (pessimistically locked) in a multiuser environment, the record remains locked from the time Edit is used until the Update method is executed or the edit is canceled. If the LockEdits property setting is False (optimistically locked), the record is locked and compared with the pre-edited record just before it is updated in the database. If the record has changed since you used the Edit method, the Update operation fails. Microsoft Jet-connected ODBC and installable ISAM databases always use optimistic locking. To continue the Update operation with your changes, use the Update method again. To revert to the record as the other user changed it, refresh the current record by using Move 0
.
Note To add, edit, or delete a record, there must be a unique index on the record in the underlying data source. If not, a "Permission denied" error will occur on the AddNew, Delete, or Edit method call in a Microsoft Jet workspace, or an "Invalid argument" error will occur on the Update call in an ODBCDirect workspace.