Select to view content in your preferred language

Bug with ArcPro? Edited Features in Branch Versions Do Not Get Updated Until Restart or Change Version

221
7
Jump to solution
a week ago
Gurunara
New Contributor III

Bug with ArcPro? Edited Features in Branch Versions Do Not Get Updated Until Restart or Change Version:

A feature is edited from code (an insert, not update), and posted to a branch version.

There is an attribute rule that is applied on backend which change the values of an "inserted" record.

From code, edits are saved, and the version refreshed.

But the changes are not reflected on the feature when examined in table or map (popup info).

Only after restart, or the version is changed to another and changed back, does the changes from the attribute rule reflected.

0 Kudos
1 Solution

Accepted Solutions
Gurunara
New Contributor III

Our workflow will not require Reconcile to the default version...

Looks like found another way to update the client values...
featurelayer.ClearDisplayCache() seems to do the trick.

This can be called when doing edit saves from code behind. As for when manual saves are being done via ArcPro, can hook into:

EditCompletedEvent.Subscribe event to check for the layer of interest being saved and call ClearDisplayCache there too...

there check for args.CompletedType == EditCompletedType.Save to detect when the save operation is being performed.

the only thing is when args.CompletedType == EditCompletedType.Save, the layer information doesn't seem to be available... so have to check for it when args.CompletedType == EditCompletedType.Operation and save that to some temporary variable and check for that in args.CompletedType == EditCompletedType.Save...

wish the layer information was available at args.CompletedType == EditCompletedType.Save

ref: https://github.com/esri/arcgis-pro-sdk/wiki/ProConcepts-Editing#editcompletedevent

 

 

View solution in original post

0 Kudos
7 Replies
Aashis
by Esri Contributor
Esri Contributor

What version of the Pro and Enterprise are you using @Gurunara?

0 Kudos
Gurunara
New Contributor III

Enterprise: 11.2 

ArcPro: 3.2.2

For update requests, the changes are reflected immediately on the map before after saves.

But for new (insert) operations, whether an attribute rule is run on the backend or not to update the values of some fields in the incoming request, the changes are not reflected before after saves. One can see the new feature on the map, but fields which get assigned default values on the backend for e.g. from an attribute rule run are not reflected "until" one restarts ArcPro or changes the version to another and back.

0 Kudos
Gurunara
New Contributor III

Seems the update changes are available immediately since the changes are made on both the client and server side. But the inserts are not available, since the updated values are available only on the server side.

So this may be a "refresh" issue..?

Currently doing refresh 2 ways:
1) from ArcPro, under Verioning tab, click on Refresh button
2) from code:

QueuedTask.Run(() =>
{
using (var geoDatabase = featureLayer.GetFeatureClass().GetDatastore() as Geodatabase)
using (var versionManager = geoDatabase.GetVersionManager())
using (var version = versionManager.GetCurrentVersion())
{
version.Refresh();
}
});

Neither seems to update values from the backend. I can see the updated values resulting from changes from the attribute rule run on the backend when querying directly via feature service url query tool (by setting the "Geodatabase Version Name:"), but those changes don't seem to be reflected on the map by performing the refresh by above 2 methods...

Is there another refresh method one needs to use, for e.g. refresh on the featurelayer or map level, not a version refresh..?

0 Kudos
Gurunara
New Contributor III

But is this a bug with ArcPro, since how would a normal user of ArcPro see the change if there is no code behind of refresh of the values (even if there is a way to refresh the values from code-behind)..? I.e. if user does a manual save of edits, the values for inserts which occur on the backend via attribute rules are not reflected, until he/she restarts or change version and back..?

0 Kudos
Gurunara
New Contributor III

Also currently doing invalidate on the new row did not work:

using (Feature feature = featureClass.CreateRow(rowBuffer))
{
// To Indicate that the attribute table has to be updated
context.Invalidate(feature);
}

0 Kudos
Aashis
by Esri Contributor
Esri Contributor

Have you called Version.Reconcile to pull updated changes from the default version after the Post? After the Reconcile, you will notice features' record change ( insert, update, or delete) from the target version ( default in branch) are applied to your edit version. 

0 Kudos
Gurunara
New Contributor III

Our workflow will not require Reconcile to the default version...

Looks like found another way to update the client values...
featurelayer.ClearDisplayCache() seems to do the trick.

This can be called when doing edit saves from code behind. As for when manual saves are being done via ArcPro, can hook into:

EditCompletedEvent.Subscribe event to check for the layer of interest being saved and call ClearDisplayCache there too...

there check for args.CompletedType == EditCompletedType.Save to detect when the save operation is being performed.

the only thing is when args.CompletedType == EditCompletedType.Save, the layer information doesn't seem to be available... so have to check for it when args.CompletedType == EditCompletedType.Operation and save that to some temporary variable and check for that in args.CompletedType == EditCompletedType.Save...

wish the layer information was available at args.CompletedType == EditCompletedType.Save

ref: https://github.com/esri/arcgis-pro-sdk/wiki/ProConcepts-Editing#editcompletedevent

 

 

0 Kudos