When your feature edits are complete and saved to the relevant table in the local geodatabase (ServiceGeodatabase or Geodatabase), you can persist edits to the feature service. The sections below describe how to persist edits in the online and offline editing patterns.
-
Apply local edits from a service geodatabase (online) — describes a service geodatabase, geodatabase behavior, ways to obtain a service geodatabase, and how to apply edits to the feature service to which the geodatabase is connected. The section also explains the advantage of using the
ServiceGeodatabaseto get a feature table rather than using theServiceFeatureTableconstructor. Finally, there is a brief discussion of applying edits with branch versioning. -
Synchronize local edits from a geodatabase (offline) — describes how to synchronize edits with a sync-enabled feature service and briefly discusses synchronizing edits with branch versioning.
Apply local edits from a service geodatabase (online)
A ServiceGeodatabase is the basis of the online feature service editing pattern. You access a feature service to create a ServiceGeodatabase instance in your app and stay connected to the service during the editing process. A service geodatabase generally contains multiple feature tables and provides functionality that realistically models the behavior of real world features. While performing editing operations, the geodatabase takes an active role to ensure the integrity of your data, often augmenting edits made directly to the data with automated changes or validation. Such changes are referred to as geodatabase behavior.
Geodatabase behavior
Examples of service geodatabase behavior include the following.
-
Composite relationships: Causes a feature in the destination table to be deleted when a related feature is deleted in the origin table.
-
Feature-linked annotation: Text in feature-linked annotation reflects the value of a field or fields from a feature in another feature class to which it is linked.
-
Utility network association deletion semantics: Values in the
UtilityAssociationDeletionSemanticsenum describe how deleting a feature of a specific asset type affects associated features. -
Attribute rules: User-defined rules that can automatically populate attributes, restrict invalid edits during edit operations, and perform quality assurance checks.
These capabilities are honored by the ServiceGeodatabase class because it is a container for all the feature tables connected with a given feature service. As a consequence, the service geodatabase is able to respect and apply the defined behaviors, assuring data integrity.
The service geodatabase allows you to manage edits for the tables it contains, such as checking if the service geodatabase has local edits, applying all edits to the service, or undoing all local edits. These operations affect all service feature tables in a service geodatabase. Additionally, when the service geodatabase supports branch versioning, you can get the available versions for the geodatabase, switch the current version, or create a new version. See the Branch versioned data topic for more information.
Get a service geodatabase
A common way to obtain a ServiceGeodatabase is by loading an existing Map or Scene (from a web map, web scene, mobile map package, or mobile scene package). A ServiceGeodatabase is created automatically for every feature service that is referenced in the map or scene. To access the service geodatabase, use Map_Tables or Scene.Tables and obtain a table from the collection, verifying whether it is a ServiceFeatureTable. Then use ServiceFeatureTable.ServiceGeodatabase to begin working with the service geodatabase. Keep in mind that a map or scene might have multiple geodatabases if it contains tables from different feature services.
To load all feature tables inside the service geodatabase, use ServiceGeodatabase_ConnectedTables
If you are interested in only one feature table in a service geodatabase, you can obtain the geodatabase and call ServiceGeodatabase.GetTable() with the table id. This is the recommended approach, rather than creating a new ServiceFeatureTable using its constructor.
Apply edits from the service geodatabase
After making edits to data within a feature table, the edits need to be packaged and sent to the feature service. Use the ServiceGeodatabase.ApplyEditsAsync() method to send all changes in all tables to the service as a single transaction. This ensures that geodatabase behavior is appropriately leveraged.
// If the feature table is a service feature table, send these edits
// to the online service by applying them to its service geodatabase.
var gdb = table.ServiceGeodatabase;
IReadOnlyList<FeatureTableEditResult> editResults = await gdb.ApplyEditsAsync();
While it is also possible to call apply on a ServiceFeatureTable, you should be aware of the implications. The advantage of calling ServiceGeodatabase.ApplyEditsAsync() on the service geodatabase, rather than [on each individual table](#apply-edits-from-a-stand-alone-feature table), is that it ensures that all of the edit operations take place in a single transaction. Either all of the edits are applied or none of them. If you apply edits to each table individually, it is possible that only some edits will be applied (for example, if you lose network connectivity in the middle of the operation).
Apply edits to a stand-alone service feature table
You can create a single ServiceFeatureTable in your app, using the service feature table's constructor, even if the table is part of a service feature geodatabase with multiple feature tables. However, this table will be disconnected from the other tables; it will be considered a stand-alone data store, without any geodatabase behaviors. If the feature table is truly stand-alone, this approach can work for your app. In that case, you should edit features, save the changes back to the table, and apply local edits by calling ServiceFeatureTable.ApplyEditsAsync().
Apply edits in a branch version
The edits made to service feature tables from a branch version can be applied by calling ServiceGeodatabase.ApplyEditsAsync() as described previously to ensure all the edits in the local tables are applied correctly to the feature service. These edits, now applied to the service, are contained to the branch version. In order to merge these changes from a branch version into the default branch version, a back-office operation is required. Using ArcGIS Pro, a GIS professional can reconcile and post the branch version into the default version so that viewers of the default branch can see the edits. See Branch version scenarios for more information on this multiuser editing workflow.
Synchronize edits from a geodatabase (offline)
Offline data downloaded from a feature service or an offline map can be edited locally without a network connection using a GeodatabaseFeatureTable that is created from a sync-enabled feature service before going offline. It is through this class that the following edit operations are performed:
The local changes can optionally be synchronized back to the feature service when the application is connected again. See Synchronizing edits documentation for more details.
Synchronize edits in a branch version
The edits made to a GeodatabaseFeatureTable from a branch version are no different than when working with offline data downloaded from a feature service or an offline map. The local changes can optionally be synchronized back to the feature service when the application is connected again. See Synchronizing edits documentation for more details. After the edits have been synchronized to the service, they are contained to the branch version. To merge these changes from a branch version into the default branch version, a back-office operation is required. Using ArcGIS Pro, a GIS professional can reconcile and post the branch version into the default version so that viewers of the default branch can see the edits. See Branch version scenarios for more information about this multiuser editing workflow.