Editing fails to save

2943
3
04-23-2013 10:59 PM
Labels (1)
MatthewBrown1
Occasional Contributor
Hi,

I have a script that creates map packages based on a template for different input data (in different locations). The schema and coordinate system are identical, however edits to scripted packages fail to save. They draw in the application and are visible on the map (as graphics), but they fail to persist between sessions. No error is returned by the application.

I have found that the cause is a difference in "GeometryDef grid size 1" between the template and scripted feature classes and the issue is resolved by adding the same grid size to the CopyFeatures args. What I don't understand is why the spatial grid would stop the edits from saving.

I'm not 100% sure, but I think this wasn't an issue prior to 10.1.1.

Thanks,

Matt
0 Kudos
3 Replies
DavidMartin
Occasional Contributor II
Is this any help (see the section on "The Spatial Index Grid Size is Invalid")?

http://resources.arcgis.com/en/help/main/10.1/index.html#//01m600000046000000
0 Kudos
MatthewBrown1
Occasional Contributor
Hi David,

I think you might be right with that link, although the grid index values don't differ that much and the edits are within the extents of the parent dataset on which the feature service is based.

Also I'm not getting an error in the Runtime and there's nothing in the logs to suggest that the edit has failed.
0 Kudos
MatthewBrown1
Occasional Contributor
I looked for an arcpy function that would return the value of "GeometryDef grid size 1" for an existing feature class so I could use this as an argument for CopyFeatures, but I was unable to find anything. Looks like you need to use ArcObjects to expose that.

Something like
arcpy.env.maintainSpatialIndex = True

to stop the grid index size changing during CopyFeatures or DeleteFeatures would be good, but the help http://resources.arcgis.com/en/help/main/10.1/index.html#//001w0000003r000000 says it's for ArcSDE, while I'm using File GDB.

Using
arcpy.CalculateDefaultGridIndex_management(inputFC) 

on the existing feature class and using the result as an argument in CopyFeatures seems to be a good workaround.
0 Kudos