All related changes to objects in the database within an edit session should be grouped into edit operations. An edit operation is begun using the StartEditOperation method. An edit operation may be thought of as a short transaction nested 嵌套的within the long transaction corresponding to the edit session.
All edits to features that participate in a Topology or Geometric Network must be bracketed within an edit operation.
When using StartEditOperation, proper handling of errors, including the use of AbortEditOperation, is neccessary.
An edit session may be started using the StartEditing method. The withUndoRedo parameter can be used to suppress undo/redo logging if the workspace supports such suppression. Note that Undo/Redo logging is not supported for remote database workspaces. StartEditing cannot be called when a edit session is already active. StopEditing must be called first before a new edit session can be started.
Note: With non-versioned editing always be sure to check the current EditState via ::IsBeingEdited before called StartEditing or StopEditing. If the workspace is being edited outside your context, there is no need to call ::StartEditing.
这也是我们所说的事务,如果想操作能返回和重做,就必须把代码写在IWorkspaceEdit的StartEditing()和StopEditing()函数之间,把相关的操作写在IWorkspaceEdit的StartEditOperation()和StopEditOperation()之间。
- All object editing should be done within an edit session.
- Group changes into edit operations.
- Discard all references to row objects retrieved at the edit session boundary (on StartEditing). If references to row objects will be maintained across edit operations then discard all references and refetch objects in response to the Undo, redo and abort edit operation calls made by the application as well as the reconcile call made within an edit session on versioned databases. In the context of ArcMap, these calls are made by the editor which broadcasts corresponding editor events via the IEditorEvents and IEditorEvents2 interfaces. Personal and enterprise geodatabase workspaces support the IWorkspaceEditEvents and the IVersionEvents outbound interfaces and directly broadcast these events.
- Use non-recycling search cursors to fetch objects that are to be updated (using any of the Search, GetRow, or GetRows methods supported by tables, feature classes and selection sets). Recycling cursors should be used only for drawing and read-only access to object state.
- Always fetch all properties of the objects to be edited. Query filters should always use “*” for the sub fields property (attempts to instantiate non-recycling cursors with less than all fields will still result in all row object fields being hydrated).
- After changing a row object, mark the object as changed and trigger propagation of the OnChanged message, as well as propagation of messages to related objects by calling the IRow::Store method on the object. Delete objects by calling the IRow::Delete method on the object triggering the OnDelete message. Stored and deleted objects within an edit operation are automatically and periodically flushed to the underlying database as needed to ensure read/query consistency and update efficiency. Use the set versions of these methods (for example, IRowEdit::DeleteSet) if updates or deletes are being made to a set of objects in order to increase performance.
- Update and insert cursors are bulk data loading and data update API’s designed for performing direct updates and inserts, outside of an edit session, on simple data, during the data loading phase of a project. Avoid using these API’s in editing applications. Using these API’s within an edit session or on complex objects (objects with non-simple row or feature behavior or on objects participating in composite relationships or relationships with notification) negates any performance advantages they may have. For more information related to the above rules, see the documentation in this chapter on rows, objects, features tables, object classes, and feature classes.