Select to view content in your preferred language

canUpdateFeature returning false when geometry updated

618
5
07-11-2019 01:16 PM
MichaelDavis3
Frequent Contributor

When users save a record in our apps I check if the feature can be updated, and if not I add the feature instead.  In a recent app (100.5) we've noticed that if the user updates the (point) geometry canUpdateFeature is returning as false and triggering the creation of a duplicate feature in the geodatabase.

Is this the expected behavior?  Should I be detecting an existing feature in another way?

0 Kudos
5 Replies
MichaelDavis3
Frequent Contributor

This appears to be due to the new point being outside the replica extent.  Not sure yet though because our users were definitely out inside the extent when editing field points and we got duplicate records.

0 Kudos
Nicholas-Furness
Esri Regular Contributor

Sorry for the delay in getting back to you, Michael Davis. Did you manage to resolve this?‌

0 Kudos
MichaelDavis3
Frequent Contributor

Yes - not sure exactly why it was happening, but editing the geometry was triggering "false" on canUpdateFeature and was then being added as a new record by our app.  Changing the extent of our .geodatabase file to cover the whole planet resolved the issue for us.

As far as I can tell neither the original geometry or the updated geometry were outside of the service's maximum extent which is what we were previously using for our offline .geodatabase extent... so still not sure what was up.

0 Kudos
Nicholas-Furness
Esri Regular Contributor

I've found out a little more from the team. When you take a .geodatabase offline with a target extent, any edits outside of it are considered invalid.

It sounds like what you're seeing isn't covered by the above rule, so I'd be interested to see what your replica's target extent and the service's full extent are.

It would also be helpful to understand what the edited geometry is when this is triggered.

0 Kudos
MichaelDavis3
Frequent Contributor

Interesting - so would it be correct to assume that edits are considered invalid but new features can still be added?  That would explain why those features were able to be saved as new features.  It created duplicates, which was inconvenient, but that's better than not saving at all.

Previously we were using featureServiceInfo.fullExtent to define the limits of our replica... for this specific service that is defined as:

Full Extent:

      XMin: -1.966968105025479E7
      YMin: 4584716.816155555
      XMax: -1.3670387279936444E7
      YMax: 1.1525350761196049E7
    Spatial Reference: 102100  (3857)
0 Kudos