My Feature Service Won't Allow Edits on Certain Features?

[MicahBabinski]

Hello,

A week or so ago I published an editable feature service for a colleague who wants to use Collector for some field data editing. However, when I try to edit the data through a web client, some features I am able to edit, while others revert back to what they were (geometry and attributes). So in essence my problem is that some features can be edited while others can't.

It is an on-premise ArcGIS Server (10.2) editable feature service referencing a polygon feature class in a non-versioned SDE (SQL Server) geodatabase (also v10.2). I have enabled all editing privileges as such:

The data is in Web Mercator, with editor tracking, and a relationship class with a 1-M relationship with a non-spatial table. There's no messaging in the relationship class. The project partner just wants users to be able to view the related records but the only edits will be to the spatial data. The properties of the relationship class are:

I've spent a lot of time researching the existing documentation of editable feature services and even our lead ArcGIS Server guy is somewhat at a loss. Has anyone observed this behavior before? It's weird because I can commit edits on certain features without issue, but for some the geometry and attributes switch back to what they were after a while. Please help!

Warm Regards,

Micah Babinski

City of Portland, Oregon

[AnthonyKobah]

Am not sure which platform is running your Collector App. Editing related records requires Server 10.3.

See this link. Also make sure the ArcGIS Server account has full access to all data.

What do you see in the ArcGIS Server log files when your edits fail?

[MicahBabinski]

Hi Anthony,

Thank you for the reply. We have tested the Collector app on Android and iOS - using a smartphone and iPad respectively. The devices are using version 10.3 of Collector app itself.

Re-publishing without the relationship class is the next thing that I will try. I was hoping it would work since the users will not actually be editing the related table - only viewing the rows. Indeed, I was able to successfully edit some vector features which had related records using the app.

I will re-publish without the relationship class to see if that works.

[AnthonyKobah]

The logs will help to diagnose the reason for the failed edits. Up the logging level to say Verbose or debug, repro the error and check back in the logs for clues.

[MicahBabinski]

Ok, I've removed the relationship class and the same error occurred when trying to edit certain features.

A couple of things caught my attention when looking at the logs:

INFO

Apr 9, 2015, 12:05:03 PM

xssInputRule = rejectInvalid

Private/BES_Invaders.MapServer

INFO

Apr 9, 2015, 12:05:03 PM

xssPreventionRule = input

Private/BES_Invaders.MapServer

INFO

Apr 9, 2015, 12:05:03 PM

xssPreventionEnabled = true

Private/BES_Invaders.MapServer

SEVERE

Apr 9, 2015, 11:59:51 AM

Failed to rename cache folder.

Private/BES_Invaders.MapServer

Do these mean anything to you? I am not very experienced at interpreting these logs. A quick lookup tells me that the xssPreventionRule can block potentially harmful attribute edits. Could this be causing the issue?

Thanks so much.

[AnthonyKobah]

Given that some edits pass through and others don't, I wont rule the xssInputRule  as the cause of the rollback.

[MicahBabinski · Accepted solution]

I found the reason for this with the help of my database administrator. The problem was that, upon importing the data into my SDE geodatabase (using the standard copy/paste method in ArcCatalog), a date field was converted to a SQL date type that was incompatible with some of the values in the rows.

The specific system date field type was "smalldatetime" which apparently cannot store any dates beyond June 6, 2079. Since quite a few rows in the table had a value for that date field of 2099 or beyond, updates to that row in SQL Server were not possible, and the edits were rolled back upon failure. I tried changing some of the values to a more recent date, and all of a sudden updates were possible for those features!

Next, I plan to check with the project partner to see if that date field is even necessary, if we can change it to a text field, or if we can change it to a more robust date field type through SQL Server.