IFeature.Store() intermittently throws HRESULT E_FAIL COM exception

[TomCohen]

I have an ArcMap add-in which is updating fields for a collection of line features within a loop. After updating values for these fields I call the Store() function of the IFeature-implementing feature (each store is correctly contained within IWorkspaceEdit.StartEditOperation and StopEditOperation, and the loop within StartEditing and StopEditing).

The same features (so far I know of 2, in a sample of more than 10,000) will regularly cause the Store() function to return "Error HRESULT E_FAIL has been returned from a call to a COM component." with no indication why. I can't see anything obviously different between successful features and failing features (i.e. unusual geometry values, special characters in attributes) so I'm stumped as to what's causing this. If I swallow the error and carry on the add-in continues to function as expected until the next failing feature is encountered.

The features can have a relationship to an annotation feature class, but by the first fail roughly half of the processed features do have a relationship and the others don't, so I can't say it's related to this association.

I currently get the source data from a personal geodatabase (.mdb) but the same problem occurs in the SDE system the features were exported from. When I received it the mdb required upgrading to the v10 format, but I got the same behaviour before and after this upgrade.

Can anyone suggest any reasons why this error might be occurring on only *some* of my features, and if there is any way to find out more about the error? I find COM exceptions the single most frustrating aspect of my day job.

[JeffMatson]

Typically it will be a geometry issue, are you first checking to see if the feature.shape is null, and then calling ITopologicalOperator.Simplify before storing the feature?

If that doesn't work maybe you can post a sample of your database including the annotation relationship along with the code block where the failure occurs.

[TomCohen]

Thanks for the quick reply and your suggestions Jeff, I'll give those things a go and post back with results

[TomCohen]

So I tried checking the geometry of the failing features - all were not null and passed through the ArcView toolbox Check Geometry tool without a problem. I also tried the ITopologicalOperator's simplify function but this also made no difference.

If I export the features that are causing issues to a separate shapefile or a new layer in the PGDB and just process these features the issue goes away. At first I thought this meant something super weird must be going on, but now I'm thinking it's more to do with the annotation - as the associations and associated layer aren't being exported at the same time.

If I can re-create the annotation associations in the exported features and then replicate the issue I'll post some data up here along with the code.

[TomCohen]

More weird behaviour with this issue - it turns out if I catch the exception being thrown by the .store function and run the same feature, with the same changes, back through the function it works, until the number of features being processed hits some magic (currently unknown) number and then even repeated store attempts fail.

Now this is really weird as it surely couldn't be down to the properties of the feature as it would fail every time?

I also tried varying the logic by using the IFeatureCursor.update method and I seem to get more frequent failures - though I'm not sure if this is just because the dataset is being traversed in a different order and I'm just seeing another bunch of failing features sooner.

Unfortunately I am only able to replicate this issue using the PGDB file I was given as an export of an SDE database - I don't have access to the SDE and the PGDB is too big to post anywhere. Exporting the failing subset to any other format seems to make the issue go away, but this is not an option for the actual users of the tool.

[JeffMatson]

More weird behaviour with this issue - it turns out if I catch the exception being thrown by the .store function and run the same feature, with the same changes, back through the function it works, until the number of features being processed hits some magic (currently unknown) number and then even repeated store attempts fail.

Now this is really weird as it surely couldn't be down to the properties of the feature as it would fail every time?

I also tried varying the logic by using the IFeatureCursor.update method and I seem to get more frequent failures - though I'm not sure if this is just because the dataset is being traversed in a different order and I'm just seeing another bunch of failing features sooner.

Unfortunately I am only able to replicate this issue using the PGDB file I was given as an export of an SDE database - I don't have access to the SDE and the PGDB is too big to post anywhere. Exporting the failing subset to any other format seems to make the issue go away, but this is not an option for the actual users of the tool.

It's hard to tell what could be happening without looking at your code, I'm assuming you are using a non-recycling cursor, and bracketing each edit inside StartOperation and StopOperation?  What happens if you delete all the features that cause an exception the first time, then run it again?

[KelvinFox]

I am having the same exact issue as you are.  The IFeature.Store() method is failing for me also.  My client is running on ArcSDE 9.3.1.  It is not consistent as you describe in your post.  I have a custom class extension for which a routine is implemented to delete or update the polygon object.  This same codebase is running fine at other similar installations without problems.

[TomCohen]

I also just had the issue come up in a totally different project - interestingly I have only seen this since moving a couple of tools to v10 add-ins, but I'm not sure that's the root of the issue.

So far my 'fix' is to make up to 3 attempts to call store() on the same feature, and if it errors every time I add the object ID to a list that gets reported to the user. If too many object IDs get pushed into the fail list the tool gives up. I'm still amazed that most of the errors go away on the second store() call.