Collector for Android Bug - Copy feature that has attachment

Question

I'm still working with support, but I'm posting in case anyone else sync problems that could be due to this issue.

The bug occurs when I use continuous stream or copy features that have photo attachments; in other words, "Like the last one" functionality.

* My features are displaying the same attached photos. Sync Fails.
* If i delete one they both lose all photos. Sync Still Fails.
* If I delete all features. Empty Sync Succeeds.

Here are images of the 1st and 5th test feature i took. for each feature i copied the previous and attached a photo via camera. but the 1st feature shows the attachments collected on the later features.

Here is what happens on the 1st sync attempt

During second attempt, the progress bar quickly moves to 99% but hangs indefinitely.

Details:

10.3 version of Collector on 2 different Samsung Tab 3 7" and a Samsung S5

Reproduced in 2 different web maps with same hosted layers

Arcmap's Copy Runtime Geodatabase to File Geodatabase tool produces features with duplicate attachments.

Could not reproduce in different hosted layers in separate web map. The attachments were not carried over when copying a feature

Initial download for offline mode has no issues

I'll update when this gets resolved.

DavinShokes1 · Answer

I would imagine that this is difficult to reproduce  because the feature service was originally published in 2013. I cannot  put out a new version until field staff complete their work this week. As a side effect, the 1400 photo attachments are currently eating 90 credits a day in feature storage fees. Chomp chomp.

RussRoberts · Answer

I cannot reproduce the issue you are seeing but will keep looking into it. The app should not copy over the GlobalID field, Editor Tracking info and attachments when copying features. We also block copy in maps with related features and/or tables (we treat the attachment relationship differently) to reduce the chance of data errors. This is something we would like to improve upon in a future update.

DavinShokes1 · Answer

Well I solved it and this is indeed a bug. The feature service in question was republished and was given a new field for GlobalIDs. So it has a string field named "GlobalID" and an esriFieldtypeGlobalID field named "GlobalID_2". Copying features also copies the value that should be unique! This is why the first feature that is copied has the photo attachments of future features.

Perhaps other sync issues are related to this failure to generate unique IDs.

Be careful what your users copy!

Edit: I read something interesting about copying with relationships:

http://resources.arcgis.com/en/help/main/10.2/index.html#/Relationship_class_properties/004t00000004000000/

* When you split a feature, the original feature is maintained (with updated geometry), and a new feature is created. If you have a relationship based on the original ObjectID, only one of the two features created in the split will maintain the relationship. However, if you used another field as the key, when you split the feature, the ID value of the original feature would be copied to the two new features. As a result, the records in the related table would now be related to both new features—ideal if the relationship class is set up as many-to-many.If you won't be splitting features and are sure that all objects will remain in their original class, you can use the ObjectID as their IDs. If you can't guarantee this, it's best to set up and use your own ID field instead of relying on the ObjectID field.