Persist edits

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 ServiceGeodatabase to get a feature table rather than using the ServiceFeatureTable constructor. 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 UtilityAssociationDeletionSemantics enum 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 ArcGISMap or ArcGISScene (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 ArcGISScene.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.applyEdits() method to send all changes in all tables to the service as a single transaction. This ensures that geodatabase behavior is appropriately leveraged.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
        lifecycleScope.launch {

            // Send these edits made in the service feature table to the online service by applying them to the table's service geodatabase.
            val serviceGeodatabase = serviceFeatureTable.serviceGeodatabase
                ?: return@launch logErr("Could not get service geodatabase from table.")

            val featureTableEditResultList = serviceGeodatabase.applyEdits().getOrElse { error ->
                return@launch logErr("Could not apply edits to service geodatabase: ${error.message}")
            }
            // Use the feature table edit results to view the applied edits.
            featureTableEditResultList.forEach { featureTableEditResult ->
                featureTableEditResult.editResults.forEach { featureEditResult ->
                    // The edit result for one feature.
                }
            }
        }

While it is also possible to call applyEdits() on a ServiceFeatureTable, you should be aware of the implications. The advantage of calling ServiceGeodatabase.applyEdits() 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 from a stand-alone 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.applyEdits().

Apply edits in a branch version

The edits made to service feature tables from a branch version can be applied by calling ServiceGeodatabase.applyEdits() 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 local 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:

• Add features,

• Update features, and

• Delete features.

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.

Related links

• Introduction to building offline applications

• Offline maps, scenes, and data

• Prepare data

• Edit features